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This  report  describes  the  Battlefield  Environment  Model  (BEM),  a 
computer  model  implemented  by  MITRE  for  use  in  conducting  simulations  of 
military  combat.  Specifically,  the  model  simulates  Red  unit  observables 
against  which  Blue  sensors  can  operate.  The  modeling  effort  employs  object- 
oriented  programming  techniques  using  the  RAND-developed  ROSS 
programming  language.  The  BEM  provides  a  stream  of  realistic  sensor  reports 
for  ANALYST,  an  expert  system  for  determining  battlefield  activity.  In 
addition,  the  BEM  provides  an  experimental  environment  for  studying  (cj, 
structures  and  various  approaches  to  sensor  tasking.  Future  enhancements  of 
the  BEM  are  also  presented. 
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This  report  was  prepared  to  provide  a  description  of  the  MITRE 
Battlefield  Environment  Model  (BEM),  a  computer  model  used  in  conducting 
simulations  of  military  combat.  The  BEM  model  is  designed  to  generate  Red 
unit  observables  against  which  Blue  sensors  can  operate;  specifically,  it  is 
designed  to  generate  sensor  observables  from  a  Soviet  division-sized  force  at 
company  resolution.  With  this  model,  enemy  tactical  events  such  as 
movement,  communications,  artillery  and  air  defense  firings,  and  radar 
emissions  are  generated  and  subsequently  detected  by  Blue  (NATO)  force 
sensors.  The  resulting  stream  of  sensor  reports  is  sent  by  the  BEM  to  the 
ANALYST,  an  expert  system  used  to  determine  enemy  tactical  disposition  on 
the  battlefield. 

Both  the  BEM  and  the  ANALYST  are  enhancements  of  previous  models 
which  employed  conventional,  procedural  programming  techniques.  The 
predecessor  of  the  BEM  was  the  MITRE  Threat  Event  Generator  (MTEg/1,2\ 
a  model  written  in  Pascal  which  generated  sensor  reports  by  parametrically 
filtering  the  observables.  The  BEM  evolved  from  this  model  through  three 
significant  enhancements: 

o  a  more  realistic  threat  representation. 

o  a  cause  and  effect  modeling  of  sensor  detections. 

o  implementation  using  object-oriented  techniques  and  the  ROSS 
programming  language  (to  be  discussed). 

The  current  ANALYST^  is  LISP-based  and  is  operational  on  both  a  VAX 
11/780  and  a  LISP  machine. 


1.2  Object-Oriented  Pr 


1.2.1  General 


The  essence  of  object-oriented  programming  is  that  it  is  centered 
around  objects  (actors  in  the  simulation)  which  communicate  with  each  other 
by  way  of  messages.  Features  of  the  technique  provide  promise  to  overcome 
many  of  the  limitations  of  conventional  procedural  programming  in  the  areas 
of  intelligibility,  modifiability,  understanding,  and  performance 
characteristics.  (See  MITRE  WP83-W004074  for  an  evaluation  of  the  use  of 
object-oriented  programming). 

The  remainder  of  this  section  provides  a  discussion  of  object-oriented 
languages  in  general  and  of  ROSS,  the  object-oriented  language  in  which  the 
BEM  is  implemented. 
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The  use  of  object-oriented  programming  for  simulation  purposes  requires 
that  simulation  objects  be  created  to  represent  the  systems  being  simulated 
(e.g.,  the  military  units).  Those  objects  must  have  characteristics  and 
behaviors  sufficiently  defined  for  them  to  adequately  portray  the  system  or 
units  being  represented. 

Objects  have  property  lists  and  behaviors  associated  with  them.  The 
properties  can  represent  such  items  as  the  numbers  of  vehicles,  location,  and 
radio  frequencies.  Behaviors  are  the  actions  taken  by  the  objects  upon 
receiving  a  message.  Both  properties  and  behaviors  may  be  modified  during 
the  simulation. 

There  are  two  types  of  objects  called  basic  and  auxiliary  objects.  Basic 
objects  are  actors  in  the  simulation  and  have  some  real-world  representation 
such  as  the  military  units  being  simulated.  Auxiliary  objects  assist  in  the 
construction  and  conduct  of  the  simulation;  an  example  is  the  Mathematician, 
which  centralizes  most  of  the  computation,  thus  making  the  basic  object 
behaviors  cleaner  and  therefore  more  readable.  Basic  objects  may  be  generic 
objects,  to  represent  classes  of  objects,  or  instance  objects,  to  represent  the 
actual  unit  or  object  being  simulated. 


Objects  are  organized  into  a  hierarchy  which  permits  them  to  inherit 
properties  and  behaviors  from  ancestor  objects  in  the  hierarchy.  This  allows 
the  programmer  to  establish  the  property  or  behavior  at  the  highest  common 
level  and  aids  in  the  construction  of  the  simulation.  Inherited  properties  may 
be  modified  at  the  lower  level  before  or  during  the  simulation.  An  example  of 
a  hierarchy  used  for  implementation  is  depicted  in  Figure  1-1.  The  top-level 
object  of  the  hierarchy  is  called  "Something".  "Something"  has  properties  and 
behaviors  which  allow  it  to  be  called  upon  to  create  offspring.  In  turn,  these 
offspring  at  the  generic  level  can  be  called  upon  to  create  their  own  offspring 
at  either  the  generic  or  the  instance  level.  The  example  shows  how  a  generic 
tank  company  might  be  created  and  how  it  in  turn  could  be  asked  to  create  an 
instance  tank  company,  one  of  the  basic  objects  in  the  simulation. 

All  action  in  the  simulation  is  controlled  through  message  passing  and 
the  object  behavorial  rules.  Object  behaviors  are  in  the  form  of  IF-THEN 
rules  which  list  the  actions  to  be  taken  by  an  object  on  receipt  of  particular 
messages.  These  actions  frequently  involve  sending  messages  to  other  objects 
or  planning  for  action  to  be  taken  at  a  future  time  in  the  simulation. 

1.2.3  ROSS 

The  particular  object-oriented  simulation  system  chosen  to  implement 
the  BEM  was  the  RAND  Corporation's  Rule  Oriented  Simulation  System 
(ROSS).  ROSS  was  developed  by  RAND  specifically  to  demonstrate  the 
application  of  artificial  intelligence  techniques  to  military  combat 
simulation.^®’®' 

1.2. 3.1  ROSS  Commands.  ROSS  is  invoked  through  the  use  of 
commands  in  the  ROSS  language.  The  format  of  a  ROSS  command  is 
(  <  ask  or  tell ><  object ><  message >  ) 
where  the  parentheses  set  off  a  list  as  in  LISP,  the  language  in  which  ROSS  is 
based,  and  the  greater-than/less-than  (  =»  ,  <  )  signs  set  off  parts  of  the 

command  for  explanation  purposes.  "Ask,"  used  interchangeably  with  "tell," 
alerts  the  object  to  receive  a  message,  that  is,  it  involves  a  LISP  macro  to 
process  the  remainder  of  the  list,  sending  the  message  to  the  object. 


1.2. 3.2  ROSS  Behaviors.  The  set  of  actions  which  an  object  takes 
receipt  of  a  message  constitutes  what  is  known  as  a  behavior.  The 
command  to  give  an  object  a  behavior  is  of  the  form 

(  <askortell>  <object> 
when  receiving 
<message> 

<  action(s)>) 

Figure  1-2  gives  an  example  of  how  a  previously  created  generic  < 
"Action-Unit"  could  be  tasked  to  create  another  generic  unit  ’Tan! 
Action-Unit  would  inherit  the  behavior  ability  to  create  another  object 
the  top-level  object  Something.  The  object  property  list  is  in  the  fo 
slot-value  pairs,  e.g.,  "tanks",  and  "10,"  indicating  that  each  tank  cor 
begins  with  ten  tanks.  The  semi-colons  set  off  comments  and  are  us 
make  the  code  more  readable  or  to  provide  explanation. 

Figure  1-3  gives  an  example  of  how  a  generic  unit  could  be  task 
create  instances  of  itself  and  provide  additional  properties  to  the  instanc 

An  example  is  given  in  Figure  1-4  of  an  object  behavior.  The  ex; 
also  demonstrates  some  of  the  features  of  the  ROSS  language,  in  part 
the  abbreviation  package  which  aids  in  the  readability  of  the  code, 
behavior  is  given  to  the  generic  object  "Unit"  and  would  therefore  be  inh< 
by  all  descendants,  both  generic  and  instantiated,  of  Unit.  This  be! 
consists  of  four  actions  which  include  sending  messages  to  other  a 
sending  messages  to  the  unit  itself,  and  modifying  unit  properties. 

Another  feature  of  the  ROSS  language  demonstrated  in  the  exam 
that  of  pattern-matching.  This  feature  allows  the  use  of  symbolic  variat 
the  messages  (preceded  by  >  or  +  symbols  in  the  message  and  evalua 
the  action  part  of  the  behavior  when  preceded  by  !  or  &). 

1.3  Organization  of  the  Report 

Section  2.0  provides  an  overview  of  the  BEM  model,  a  descriptioi 
BEM  simulation,  and  a  description  of  the  components  of  the  BEM/ANAL1 
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EXAMPLE  GENERIC  OBJECT  CREATION 


(ask  tank-co  create  instance  tank-co-0355 
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work  stations.  A  more  detailed  description  of  the  BEM  is  presented  in  Section 
3.0,  which  details  the  "actor  files"  in  the  BEM  simulation.  Section  4.0 
describes  future  enhancements  of  the  BEM.  Appendix  I  and  II  contain  sensor 
and  threat  research  for  the  BEM.  Data  lists  of  threat  representation  for  the 
BEM  are  presented  in  Appendix  HI,  which  is  classified  SECRET  and  published 
separately.  Appendix  IV  presents  the  ROSS-Language  code  for  the  BEM,  while 
Appendix  V  describes  the  BEM  development  and  demonstration  facilities. 


2.0  GENERAL  DESCRIPTION  OF  THE  BATTLEFIELD  ENVIRONMENT 
MODEL  (BEM) 

2.1  Model  Overview 

As  noted  in  Section  1.0,  the  primary  purpose  of  the  BEM  is  to  produce 
realistic  sensor  reports  for  the  ANALYST,  MITRE’s  expert  system  for 
intelligence  fusion.  The  BEM  also  provides  a  testbed  environment  where 
various  C2  structures  and  approaches  to  sensor  tasking  can  be  modeled. 
Figiire  2-1  shows  a  high-level  view  of  the  BEM/ANALYST  models. 

In  addition  to  the  computer  code  necessary  to  run  a  BEM  simulation, 
there  is  a  database  related  to  the  movement  of  a  Soviet  division-level  force  in 
the  Fulda  Gap  of  Germany.  This  data  originates  in  the  Scenario  Oriented 
Recurring  Evaluation  System  (SCORES)^  which  provides  battalion-level 
resolution.  Previous  work  at  MITREf®’®)  has  expanded  this  data  to  company 
level,  and  from  this,  beginning  and  ending  times  and  positions  have  been 
generated  (See  Section  2.2.1).  Path  construction  routines  which  can  be  used 
dynamically  during  a  simulation  are  also  used  prior  to  a  BEM  run  to  generate 
routes  for  all  threat  units.  These  routes  are  constructed  with  the  aid  of  a 
nodal  network  which  includes  the  road  network  and  any  other  trafficable  path 
for  a  company-sized  unit. 

Currently,  sensor  detection  in  the  BEM  extends  only  to  the  point  of 
determining  whether  a  given  observable  event  has  taken  place  within  the 
geographic  coverage  area  of  a  relevant  sensor.  Other  considerations  related 
to  sensor  detection,  such  as  terrain  masking  and  signal  attenuation,  will  reside 
in  formal  sensor  models  and  appear  in  a  future  version  of  the  BEM. 

2.2  Input  Data 

2.2.1  Red  Units 

Red  units  in  the  BEM  represent  a  first-echelon  Soviet  division  in  the 
Fulda  Gap  area  of  Germany  on  D  +  1,  i.e.,  one  day  after  the  start  of 
hostilities.  The  division  consists  of  three  tank  regiments,  one  motorized  rifle 
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FIGURE  2-1 

HIGH  LEVEL  VIEW  OF  THE  BEM/ ANALYST  MODELS 


regiment,  their  regimental  artillery  groups,  an  artillery  regiment,  an  air 
defense  battalion,  and  combat  service  support  units.  Units  are  represented 
down  to  company  level,  with  headquarters  represented  from  battalion  to 
division  level.  Unit  positions  are  developed  for  0330  hours  and  0930  hours  on 
D  +  1  of  SCORES  European  Sequence  II  a.  Figure  2-2  depicts  the  command 
structure. 

Common  unit  data  are  developed  and  stored  at  the  generic  unit  level. 
These  data  include  the  number  and  types  of  vehicles  and  radios  and  other 
characteristics  such  as  march  length  and  speed  and  radio  nets.  Individual  unit 
data  such  as  location  and  radio  frequency  are  developed  and  stored  at  the 
instance  unit  level.  Appendix  m  (published  separately)  presents 
representative  data  at  both  the  generic  and  instance  levels. 

2.2.2  Blue  Sensors 

The  BEM  employs  five  generic  types  of  sensors: 

o  MTI  (moving  target  indicators)  which  detect  unit  movement  on  the 
battlefield. 

o  COMINT  (communications  intelligence)  which  detects  radio 
communications. 

o  CMCB  (counter-mortar/counter-battery)  which  detects  mortar, 
rocket,  missile  and  artillery  firings. 

o  ELINT  (electronic  intelligence)  which  detects  radar  emissions. 

o  IMINT  (imagery  intelligence,  specifically  photo). 

CMCB  is  only  represented  on  the  ground  while  IMINT  is  only  represented 
airborne.  All  others  are  represented  both  on  the  ground  and  airborne. 
COMINT  sensors  are  omnidirectional.  All  others  are  directional,  with  IMINT 
having  a  squared  coverage  area  directly  beneath  the  platform,  and  MTI, 
CMCB  and  ELINT  having  a  fan-shaped  coverage. 

2.3  Description  of  a  BEM  Simulation 

The  BEM  has  a  scenario  file  with  particular  events  set  to  occur  at 
specified  times  during  the  simulation.  First  among  these  events  is  the 
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delivery  of  orders  down  through  the  Soviet  military  chain  of  command 
beginning  at  division  level  and  proceeding  to  the  company /battery  level. 
Movement  of  these  threat  units  will  not  begin  before  their  start  times  as 
prescribed  by  the  SCORES  data. 

A  second  major  event  set  in  motion  by  the  scenario  file  is  the  initiation 
of  artillery  firings,  and  anti-aircraft  radar  and  firing  activity.  In  a  two-sided 
simulation,  many  of  these  events  would  be  generated  on  the  Red  side  in 
response  to  events  occurring  on  the  Blue  side.  Since  the  current  BEM  is  one¬ 
sided,  it  is  necessary  to  generate  these  events  artificially.  Once  set  in 
motion,  these  activities  can  continually  be  produced  throughout  the  simulation 
by  Monte  Carlo  techniques. 

The  third  major  activity  initiated  by  the  scenario  file  is  the  tasking  of 
ground  and  airborne  sensors.  Ground  sensors  will  travel  along  the  node 
network  until  they  reach  a  point  where  they  will  stop  and  begin  their 
mission.  Passive  sensors  (COMINT,  ELINT)  will  remain  on  for  the  duration  of 
their  mission,  while  active  sensors  (MTI,  CMCB)  will  periodically  turn  on  and 
off.  Airborne  sensors  will  start  from  and  return  to  a  specified  airport. 
Airborne  MTI,  ELINT  and  COMINT  sensors  will  fly  to  designated  points  and 
proceed  to  traverse  racetrack  patterns  with  their  sensors  turned  on  during 
each  leg  of  the  racetrack  and  off  during  each  turn.  Photo-imagery  sensors 
will  be  given  specified  flight  points  over  which  a  picture  will  be  taken. 
Although  this  preprogramming  of  sensor  tasking  allows  the  simulation  to  run 
systemically,  it  is  nevertheless  possible  to  interactively  task  sensors  during 
the  running  of  the  simulation. 

As  previously  noted,  the  current  BEM  employs  object-oriented 
programming  techniques  using  the  ROSS  programming  language.  Events  and 
calculations  occur  in  response  to  messages  sent  amongst  the  various  objects. 
Part  of  the  BEM  Controller  Station  is  a  text  terminal  which,  in  addition  to 
allowing  interaction  with  the  BEM,  can  display  the  ROSS  messages  sent  during 
a  simulation.  An  example  of  some  of  these  messages  is  shown  in  Figure  2-3. 
The  format  of  a  line  of  the  message  is  the  time  the  message  was  sent,  the 


object  to  whom  the  message  was  sent,  and  the  message  itself  with  any 
variables  evaluated  (as  is)  in  it.  The  user  may  have  all  messages  print  out  or 
only  those  of  particular  interest.  The  messages  may  also  be  sent  to  a  file  on 
the  disk.  The  complete  set  of  messages  is  an  invaluable  aid  to  debugging, 
whereas  a  carefully  chosen  subset  is  displayed  during  demonstrations  to  better 
understand  the  progression  of  events  exhibited  on  the  Ground  Truth  Display. 

2.4  BEM/ANALYST  Work  Stations 

During  the  running  of  a  full-up  BEM  simulation  (which  involves  the 
ANALYST),  user  interaction  is  accomplished  by  means  of  three  work  stations: 

o  BEM  Controller  Station 

o  Blue  Sensor  Control  Station  (BSCS) 

o  ANALYST  Station 

Figure  2-4  shows  the  current  BEM/ANALYST  Work  Station 
Configuration.  Each  of  these  stations  contains  a  keyboard  and  graphics 
display.  (See  Appendix  V  for  a  description  of  the  laboratory  configuration.) 

The  BEM  Controller  Station  controls  the  simulation  itself.  The 
simulation  is  initiated  from  the  text  terminal  of  this  station  and  can  at  any 
time  be  suspended.  During  a  suspension,  the  user  can  change  certain  kinds  of 
data  and  even  alter  sections  of  code.  The  simulation  can  then  be  restarted 
and  it  will  take  up  where  it  left  off. 

The  Blue  Sensor  Control  Station  serves  to  monitor  Blue  sensor  movement 
and  sensor  reports  coming  from  the  BEM.  This  station  also  serves  as  a  vehicle 
for  dynamically  tasking  sensors.  In  the  real  world,  intelligence  missions  are 
conducted  primarily  in  an  effort  to  discover  information  relating  to  enemy 
position  capability  and  intention.  In  the  analytical  environment,  it  is 
inappropriate  for  the  collection  manager  to  be  able  to  view  the  enemy  order 
of  battle.  For  this  reason,  the  Blue  Sensor  Control  Station  is  remoted  from 
the  BEM.  Although  its  functions  belong  in  fact  to  several  intelligence 
organizations  in  the  field,  it  has  been  useful  to  combine  them  at  one  station 
for  purposes  of  analysis. 
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FIGURE  2-4 

BEM/ ANALYST  WORK  STATION  CONFIGURATION 


All  of  these  work  stations  allow  a  user  to  move  the  cursor  to  a  point  on 
their  respective  graphics  displays  and  make  enquiries  as  to  the  nature  of  an 
object  displayed  there. 

The  next  four  sections  of  this  report  discuss  these  stations  and  their 
displays  in  more  detail. 

2.4.1  BEM  Controller  Station 

The  BEM  simulation  is  projected  graphically  onto  the  Ground  Truth 
Display.  This  display  is  comprised  of  three  functional  parts:  (1)  a  node  or 
terrain  background,  (2)  the  Red  threat  units,  and  (3)  the  Blue  sensor  units.  In 
addition,  the  activities  of  the  military  units  are  dynamically  displayed.  Figure 
2-5  shows  the  terrain  symbology  used. 

2.4. 1.1  Background  Displays 

4. 1.1.1  Trafficable  Path  Network  Background.  Threat  and  sensor 


ground  units  are  constrained  by  terrain  features  to  a  limited  set  of  trafficable 
paths.  These  paths  are  represented  by  493  nodes  in  the  BEM  simulation.  Each 
of  these  nodes  has  properties  describing  its  type  (city,  bridge,  obstacle  or  road 
intersection),  its  location,  and  any  neighboring  nodes  to  which  there  are 
trafficable  paths.  The  graphics  system  can  portray  this  nodal  network  to 
support  development  of  route  selection  criteria  or  to  enhance  other  detailed 
threat  analyses.  Figure  2-6  shows  the  current  node  network. 

2. 4. 1.1. 2  Stylized  Terrain  Feature  Background.  Demonstrations  of  the 


BEM  require  a  graphical  background  which  has  more  militarily  significant 
information.  Major  terrain  features  such  as  high  speed  roads,  major  rivers, 
and  forested  areas  need  to  be  displayed,  along  with  large  urban  centers  and 
key  bridges.  Here  the  viewer  is  able  to  watch  the  simulation  against  an 
aggregated  background  where  model  details  are  less  important  than  major 
trends  in  behavior.  This  is  the  default  background  for  the  BEM  Ground  Truth 
Display.  Figure  2-7  shows  the  terrain  display. 


2. 4. 1.2  Red  Threat  Units.  Threat  units  in  the  BEM  are  of  five  basic 
types:  tank,  motorized  rifle,  artillery,  air  defense,  and  combat  service 
support.  These  require  symbols  to  reflect  both  their  function  and  their  size, 
e.g.,  company/battery,  battalion,  regiment  and  division.  The  symbology  used 
is  similar  to  approved  military  convention  while  allowing  for  rapid  recognition 
in  a  complex  display.  Figure  2-8  shows  Red  threat  units  representing  a 
division. 

2.4. 1.3  Blue  Sensor  Units.  As  stated  earlier,  the  BEM  uses  five  basic 
types  of  sensors:  MTI,  COMINT,  ELINT,  IMINT  (photo),  and  CMCB.  The 
symbology  used  to  represent  sensors  does  not  distinguish  between  sensor  types 
but  rather  whether  the  sensor  is  airborne  or  on  the  ground.  The  symbols  were 
chosen  to  make  sensors  easily  distinguishable  from  the  Red  threat  units. 

2.4. 1.4  Enemy  and  Sensor  Activities.  The  Ground  Truth  Display 
dynamically  portrays  not  only  the  simulation  units  but  also  their  activities. 
These  are  discussed  below. 

Threat  and  sensor  units  that  move  require  a  graphics  display  of  that 
movement.  Basically,  movement  is  depicted  by  erasing  a  unit's  symbol  at  the 
current  position,  drawing  a  vector  to  the  destination,  erasing  the  vector,  and 
displaying  the  symbol  at  the  end  location. 

Military  communications  (for  the  threat  units  only)  are  represented  as 
radiating  concentric  circles  centering  on  the  transmitting  element  and  colored 
to  correspond  with  the  type  of  communications  currently  used  in  the  BEM, 
i.e.,  fire  call,  net  call,  ready  call,  control  call,  sitrep  call,  and  confirm  call. 

There  are  four  types  of  threat  radars  used  in  the  BEM:  meteorological, 
fire  control,  heightfinder,  and  surveillance.  Each  radar  "on  status"  event  is 
represented  as  the  displaying  of  a  radar  symbol  next  to  the  transmitting  unit 
in  a  color  appropriate  to  its  function. 

There  are  three  types  of  firing  events  shown  on  the  Ground  Truth 
Display:  artillery,  missile,  and  rocket.  Each  type  requires  a  separate  color 
and  is  shown  as  a  flashing  asterisk  near  the  firing  unit. 


There  are  currently  three  types  of  sensor  coverage  displayed  on  the 
Ground  Truth  Display.  Airborne  photo-imagery  is  represented  by  a  square 
with  the  current  sensor  location  in  the  center.  Omnidirectional  sensors 
(COMINT)  require  a  circular  coverage  display,  while  directional  sensors  (MTI, 
ELINT,  CMCB)  require  a  fan-type  coverage  display  with  the  origin  at  the 
current  sensor  location.  Displays  of  sensor  coverage  are  used  to  depict 

graphically  the  tactical  duty  cycle  of  particular  sensors.  Figure  2-9  depicts 
ground  and  airborne  sensors  and  their  coverages  over  the  battlefield. 

2.4.2  Blue  Sensor  Control  Station 


The  Blue  Sensor  Control  Station  (BSCS)  is  a  separate  process  from  the 
BEM,  designed  to  provide  an  interactive  window  into  the  sensor  tasking  and 
execution  functions  contained  in  the  battlefield  simulation.  Additionally,  the 
Blue  Sensor  Control  Station  displays  the  results  of  BEM  sensor  operations  in 
the  form  of  tactical  intelligence  reports  displayed  on  the  graphics  screen. 

2.4.2. 1  Utility.  The  Blue  Sensor  Control  Station  enables  the  user  acting 
as  a  collection  manager  to  formulate  sensor  taskings  for  each  of  five  types  of 
intelligence  sensors.  These  taskings  are  then  passed  to  the  BEM  for 
implementation.  Providing  there  are  available  sensors,  the  BEM  orchestrates 
the  performance  of  the  sensor  platforms  and  collection  devices.  Sensor 
platform  positions  and  coverage  areas  are  displayed  at  the  Blue  Sensor 
Control  Station  Display,  allowing  the  collection  manager  to  monitor  the 
execution  of  earlier  taskings.  The  BEM  sends  tactical  sensor  reports  to  the 
Blue  Sensor  Control  Station  which  displays  them  on  the  graphics  screen.  The 
Blue  Sensor  Control  Station  also  records  reports  in  history  files  for  use  in 
later  evaluations.  At  any  point,  the  user  can  interact  with  the  Blue  Sensor 
Control  Station  display  to  obtain  information  relating  to  a  particular  sensor  or 
report  on  the  screen.  The  mission  tasking,  monitoring,  and  assessment  cycle 
continues  throughout  the  simulation,  and  the  collection  manager  at  any  point 
can  control  sensor  employment  in  the  BEM  through  this  station. 


OVER  THE  BATTLEFIELD 


2.4.2. 2  Operation  Once  the  BEM  is  running,  the  user  then  loads  the  Blue 
Sensor  Control  Station  environment  into  a  ROSS  program  in  the  same  working 
area  as  the  BEM  and  prepares  the  station  with  the  following  command: 

(ask  station-manager  prepare  the  station) 

This  behavior  is  principally  graphical  in  nature.  It  displays  the  stylized 
terrain  background  and  the  station  menu  on  graphics  screen.  Figure  2-10  is  a 
view  of  the  station  after  this  command  is  completed. 

The  user  can  now  cause  the  station  to  begin  looking  for  sensor  position 
updates  and  sensor  reports  put  out  by  running  BEM.  The  command  to  issue  is: 
(ask  station-manager  turn  the  station  on) 

At  this  point  the  station  is  running  and  the  user  controls  its  operations 
with  the  menu  shown  in  Figure  2-10.  By  placing  the  joystick  cursor  over  the 
desired  circle  option  and  pressing  a  key,  the  user  can  select  among  the  choices 
shown. 

The  menu  shown  allows  for  selective  decluttering  of  the  display  by 
alternately  showing  or  hiding  parts  of  the  display  such  as  the  map,  sensor 
positions  or  sensor  reports,  or  the  menu  itself.  A  joystick  is  used  to  "pick" 
sensors  and  sensor  reports  whose  detailed  information  is  to  be  displayed. 

Figure  2-11  shows  the  station  during  a  simulation  with  several  sensors 
operational,  their  coverage  areas  and  sensor  reports  of  several  types  displayed 
on  the  screen.  The  station's  interactive  querying  capability  is  shown  in  Figure 
2-12,  where  the  user  has  picked  an  ELINT  sensor  report.  The  user  can  read 
the  report's  property  list  while  the  station  continues  to  process  incoming 
sensor  position  updates  and/or  additional  sensor  reports. 

2.4.3  ANALYST  Station 

2. 4.3.1  Utility.  The  ANALYST  Station  allows  the  user  to  interact  with 
the  fusion  model  and  depicts  on  a  graphics  screen  the  results  of  processing 
sensor  reports  from  the  BEM.  The  ANALYST  is  an  expert  system  which 
transforms  sensor  reports  to  meaningful  hypotheses  as  to  the  current  state  of 
the  battlefield  by  applying  various  knowledge-bases. 
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2. 4.3.2  Operation.  Sensor  reports,  collected  from  the  BEM,  are 

partioned  into  five  groups  corresponding  to  five  types  of  sensors.  Knowledge 
is  applied  to  each  group  of  sensor  reports  to  produce  localized  clusters  of 
activity  as  shown  in  Figure  2-13.  The  numbers  represent  the 
number  of  reports  making  up  the  cluster,  and  the  color  represents  the  type  of 
activity,  i.e.,  green  for  radars,  red  for  firings,  etc.  Pattern  knowledge  is  then 
applied  to  these  clusters  to  hypothesize  the  existence  of  military  entities.  If 
the  ANALYST  is  not  sure  of  an  entity  at  this  point,  it  is  shown  in  pink.  Figure 
2-14  shows  another  look  at  the  screen  with  some  military  objects  determined 
and  others  in  an  uncertain  state  (i.e.,  those  shown  in  pink). 

General  military  knowledge  is  next  applied  in  an  all-source  process  to 
refine  the  situation.  Some  information  about  known  objects  may  be 
transferred  to  those  close  by  which  are  unknown;  initial  disparities  will  be 
resolved;  and  enemy  doctrine  will  be  examined  to  approve  or  disapprove  of 
conclusions  already  made. 

Finally,  information  both  received  and  hypothesized  which  is  dated  will 
be  purged  from  the  system  after  a  certain  length  of  time.  Purged  units  are 
shown  in  dark  blue. 
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FIGURE  2-14 

ANALYST  STATION  DISPLAY  -  SHOWING  DETERMINED 
AND  UNDETERMINED  MILITARY  OBJECTS 


3.0  DETAILED  DESCRIPTION  OF  THE  BEM 

3.1  Model  Overview 

As  discussed  in  Section  1.0,  of  major  importance  in  the  design  of  the 
is  the  use  of  object-oriented  programming  techniques.  Constructing  the 
with  the  ROSS  language  was  considered  an  important  test  case  in  determ 
the  applicability  of  the  object-oriented  programming  to  other  forms  of  , 
modeling.  For  a  report  on  the  evaluation  of  object-oriented  program  min 
Army  modeling,  see  the  MITRE  Working  Paper/4^ 

As  noted  earlier,  objects  in  the  BEM  can  generally  be  divided  into 
that  have  some  real-world  counterpart  and  those  that  do  not.  This  1 
group  is  referred  to  as  auxiliary  objects,  which  perform  computations 
service  to  the  real-world  objects  of  threat  units  and  Blue  sensors.  Figur 
shows  the  ROSS  object  hierarchical  structure  of  the  BEM.  The  right 
column  headed  by  Scenario  comprises  the  auxiliary  objects  in  the  BEM. 
properties  and  behaviors  resident  at  one  level  of  this  hierarchy  ca 
inherited  by  any  actor  at  a  lower  level.  Conversely,  any  property  or  beh 
at  a  lower  level  can  overide  the  same  property  or  behavior  resident 
higher  level.  Thus,  in  order  to  save  space,  properties  and  behaviors  ii 
BEM  are  placed  at  the  highest  level  of  commonality. 

The  primary  purpose  of  the  BEM  is  to  generate  realistic  sensor  rep 
So  that  this  function  may  be  better  understood  in  the  BEM/ROSS  environn 
Table  3-1  portrays  the  major  elements  of  controlling  sensors  and  of  s< 
detection  of  Red  units.  A  view  of  the  process  is  given  here  by  ste[ 
through  the  sequence  of  message  passing  from  the  first  tasking  of  a  sensoi 
the  ultimate  detection  of  a  threat  unit.  The  example  uses  an  airborne  E 
sensor  which  is  capable  of  detecting  emissions  from  Red  unit  anti-ain 
radars  if  those  emissions  fall  within  its  coverage  area.  The  messages  depi 
are  the  actual  ROSS  messages  sent. 
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FIGURE  3-1 

ROSS  OBJECT  HIERARCHY  IN  THE  BEM 


The  actor  "Scenario"  is  the  BEM's  source  of  initiating  events.  The  event 
of  interest  in  the  case  shown  in  Table  3-1  is  the  tasking  of  an  ELINT  sensor. 
This  tasking  alternatively  could  have  been  generated  by  the  Blue  Sensor 
Control  Station  through  interaction  with  the  user. 

In  the  initial  message  in  Step  1,  controll,  elint,  8,  3,  and  (50  25) 

represent  the  specific  values  of  variables  within  the  message.  All  other  words 
form  the  static  format  of  the  message.  This  message  is  sent  to  a  sensor- 
control-unit  called  Controll,  which  will  determine  which  sensor  is  available 
and  construct  a  task  and  plan  for  it  using  the  incoming  information. 

In  Step  2,  when  Controll  sends  the  message,  the  expressions  !task  and 
’.plan  will  be  evaluated  and  sent  to  the  sensor-action-unit  indicated  by  the 
variable  "sensor". 

Step  3  indicates  that  the  sensor-action-unit  will  ask  an  auxiliary  unit 
called  Flightplanner  to  construct  a  route  for  the  airborne  sensor,  and  also  ask 
another  auxiliary  unit,  Mathematician,  to  determine  when  the  coverage  area 
of  the  sensor  penetrates  (i.e.,  turns  on  in)  the  global  sector  (an  intermediary 
between  Blue  sensors  and  Red  units). 

In  Step  4,  Mathematician  will,  in  response  to  the  previous  message,  send  a 
message  to  the  global  sector  telling  it  what  sensor  has  penetrated  it  and 
sending  pertinent  additional  information  such  as  the  next  time  the  sensor  will 
turn  off. 

In  Step  5,  the  sector  will  ask  the  Mathematician  to  determine  the  time 
and  space  overlaps  between  the  ELINT  sensor  and  any  Red  radars.  The  result 
will  be  a  list  of  the  Red  radars  which  are  on  within  the  ELINT's coverage  area 
at  the  same  time  the  ELINT  sensor  is  turned  on.  Also  returned  will  be  the 
times  when  these  detections  first  occur.  When  these  times  are  reached  in  the 
simulation,  the  Sector  will  send  a  message  to  the  appropriate  sensor  to  check 
for  sensor  detection  as  indicated. 

In  Step  6,  when  this  message  is  received  by  a  generic  actor  Sensor,  the 
proposed  detection  is  passed  on  directly  to  the  Interface  telling  it  which 
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Table  3-1 

Major  Elements  of  Sensor  Control  and  Detection 


Actor 


Example  of  Message  Sent  by  Actor 


Scenario  file 


Sensor  Control  Station 


Sensor-Control-Uni  t 


Sensor-Action-Unit 


Mathematician 


"tell  controll  send  up  airborne 
elint  sensor  in  8  km  racetrack 
pattern  3  times  around  with 
initial  pt  (50  25)" 

"tell  !sensor  move  airborne  sensor 
in  racetrack  pattern  with  !task 
and  ’plan" 

"ask  flightplanner  move  airborne 
sensor  ’myself  using  racetrack 
pattern" 

"ask  mathematician  determine  pene¬ 
tration  of  global  generic  sector 
with  airborne  sensor  Jmyself" 

"tell  sector  ’sensor  has  pene¬ 
trated  the  sector  with  ’sensor- 
data" 


Sector 


Generic  Sensor  Type 


"ask  mathematician  determine 
time/space  overlaps  between  elint 
!sensor-data  and  any  red  radars" 

"tell  Isensor  check  for  sensor 
detection  of  ’unit  of  type  !type 
and  frequency  frequency" 

"tell  interface  Jmyself  has 
detected  ’unit  at  Jfrequency  and 
duration" 


Interface 


Extracts  from  the  database  the 
type  of  information  that  parti¬ 
cular  sensor  would  report  and 
sends  it  (if  required)  to  Blue 
Sensor  Control  Station  or  ANALYST 


sensor  has  detected  what  threat  unit  and  relaying  the  detected  emission 
frequency  and  duration. 

In  Step  7,  the  Interface  will  extract  from  the  unit's  database  only  the 
information  that  a  sensor  could  realistically  detect.  These  sensor  reports  can 
then  be  sent  to  ANALYST  and/or  the  Blue  Sensor  Control  Station. 

3.2  Actors  -  Actor  Files  in  the  BEM  Simulation 


The  following  sections  of  the  report  discuss  the  current  actors  in  the  BEM 
simulation  by  describing  their  purpose  and  their  major  behaviors. 

3.2.1  Simulator 

The  Simulator  is  the  highest-level  actor  in  the  object  hierarchy.  Created 
by  the  ROSS  actor  Something,  all  other  actors  are  directly  or  indirectly 
created  from  Simulator.  A  well-defined  inheritance  tree  is  thus  established 
even  though  inheritance  features  are  not  used  for  all  actors.  Simulator  is  the 
principal  BEM  object  with  which  the  user  can  control  the  simulation.  Prior  to 
the  beginning  of  a  simulation,  the  user  sends  a  message  to  the  Simulator  by 
typing: 

(ask  simulator  prepare  simulation  using  scenario  xyz). 

Upon  receipt  of  this  message  the  Simulator  will: 

o  override  certain  of  its  defaults  with  those  in  the  scenario  file 
named  xyz 

o  ask  the  graphics  generator  (the  Artist)  to  draw  the  appropriate 
terrain  background  on  the  Ground  Truth  Display 

o  ask  the  Artist  to  draw  all  of  the  military  units  on  the  Ground  Truth 
Display  in  their  initial  positions. 

When  this  is  completed,  the  user  types: 

(ask  simulator  start  simulation). 

When  the  Simulator  receives  the  "start  simulation"  message,  it: 


o 


tells  the  scenario  actor  xyz  to  "prepare  to  start  simulation"  which 
initiates  all  preprogrammed  events 


o  sets  up  a  loop  which  will  loop  once  for  every  simulation  time 
segment  (tick)  required  to  reach  the  designated  end  of  the 
simulation. 

Within  the  loop  for  every  simulation  tick,  the  Simulator  wills 

o  check  to  see  if  an  interrupt  has  occurred  which  is  the  user's 
method  for  halting  the  simulation 

o  ask  the  Artist  to  print  the  simulation  time  on  the  Ground  Truth 
Display 

o  ask  the  simulation  clock  to  advance  one  tick 

o  cause  all  sensor  reports  accumulated  during  the  tick  to  be  sent  out 
to  ANALYST  and/or  the  Blue  Sensor  Control  Station. 

The  above  two  commands  are  the  ones  required  from  the  Controller  Station  to 
run  the  BEM  simulation. 

The  user  can  also  send  the  Simulator  messages  to  start  or  stop: 
o  all  graphics  on  the  Ground  Truth  Display 

o  sending  sensor  reports  to  ANALYST  and/or  the  Blue  Sensor 
Control  Station. 

Finally,  by  sending  the  Simulator  the  message  "prepare  simulation  again,"  the 
user  can  cause  a  complete  restart  of  the  simulation  from  the  beginning 
without  reloading  the  system. 

3.2.2  Scenario 

The  Scenario  actor  is  created  by  the  Simulator  and  takes  a  name  related 
to  a  simulation  being  shown.  This  actor  contains  property  information  and 
messages  which  will  govern  how  the  BEM  simulation  will  be  run.  The  graphics 
and  timing  defaults  listed  as  properties  of  the  Simulator  can  be  overridden  by 
the  corresponding  properties  of  the  Scenario.  The  Scenario  has  only  one 
behavior.  In  response  to  the  message  "prepare  to  start  simulation,"  the 
scenario  will  send  messages  which  initiate  movement,  artillery  and  air  defense 
firings,  radar  emissions  and  sensor  taskings.  These  messages  will  be  sent  at 
specified  times  during  the  simulation. 


3.2.3  Artist 


The  Artist  is  an  auxiliary  object  which  produces  the  graphics  on  the 
Ground  Truth  Display.  It  provides  a  high-level  ROSS  interface  so  that  the 
BEM  actors  need  not  concern  themselves  with  the  details  of  graphics 
production.  In  the  BEM,  medium-level  BEM  related  graphics  routines  reside  in 
an  ARTFNS.L  library  while  BEM-  independent,  low-level  graphics  instructions 
reside  in  the  AED.L  file. 

3. 2. 3.1  The  Low-Level  Graphics  Device  Driver  (AED.L).  The  device 


currently  used  m  the  SPL  for  graphics  displays  is  the  AED  512  graphics 
terminal.  As  in  the  case  of  any  graphics  terminal,  it  has  its  own  set  of 
firmware  which  recognizes  specific  display  commands  to  produce  images  on 
the  display  monitor.  In  an  effort  to  make  the  Artist  as  device  independent  as 
possible,  these  functions  were  written  directly  in  LISP  and  placed  in  a  file 
separate  from  the  ROSS  files  for  ease  of  compilation  and  speed.  Other  SPL 
LISP-based  systems  also  use  this  file  as  the  device  driver  for  the  AED,  as  in 
the  case  of  the  VAX-based  ANALYST.  This  file  is  application  independent 
and  represents  a  LISP  graphics  library  for  the  AED  terminals.  An  example  of 
a  LISP  function  used  is: 

(draw-circle  10) 

which  draws  a  circle  with  the  origin  at  the  current  cursor  position  in  the 
current  color  with  a  radius  of  10  pixels.  This  function  generates  a  character 
stream  which  drives  the  AED  firmware  through  an  RS232  interface  to  produce 
the  circle. 

3. 2. 3. 2  Artist  Messages/Behaviors.  When  receiving  the  ROSS  message 


"display  node  network" 

the  Artist  accesses  the  BEM  node  network  data  structure  to  produce  an  image 
on  the  background  plane  shown  in  Figure  2-6.  This  display  uses  the  colors 
gray,  blue,  and  black.  The  cities  are  represented  as  blue  circles,  the  bridges 
or  obstacles  as  gray  circles,  and  the  roads  as  gray  arcs.  Black  is  reserved  to 
enable  erasure  which  is  available  by  substituting  the  word  "erase"  for  "display" 
in  the  invoking  message  pattern.  The  substitution  of  "erase"  for  "display"  is 
allowed  in  all  Artist  messages. 


When  receiving  the  ROSS  message 

"display  tic  (or  grid)  marks" 
the  Artist  will  cause  kilometer-spaced  tic  or  grid  marks  to  be  drawn  as  an  aid 
in  the  determination  of  points  of  reference.  Tic  marks  are  spaced  along  both 
the  x  and  y  axes.  Grid  marks  cross  the  entire  screen  along  both  axis.  Both  tic 
and  grid  marks  are  drawn  in  gray. 

When  receiving  the  ROSS  messages 

"display  towns  and  bridges"  and  "display  terrain  features" 
the  Artist  draws  the  stylized  terrain  display  as  shown  in  Figure  2-7.  Forested 
areas,  major  highways,  cities  and  bridges  are  drawn  with  these  messages 
where  tree  symbols  are  green,  roads  and  cities  light  blue,  and  bridges  gray. 

When  receiving  the  ROSS  message 

"place  >  shape  at  vicinity" 

the  Artist  will  draw  an  object  symbol  corresponding  to  the  value  of  "shape"  at 

the  location  specified  by  "vicinity".  All  threat  units  and  sensors  are  initially 
displayed  with  this  command. 

When  receiving  the  ROSS  message 

"move  >  actor  from  >  location  to  >  destination  using  >  shape" 
the  Artist  erases  the  specified  shape  at  the  specified  location,  draws  a  line  in 
the  appropriate  color  to  the  specified  destination,  erases  the  line,  and  places 
the  symbol  at  the  destination  to  give  an  appearance  of  object  movement.  The 
actor  variable  holds  the  actor  name  involved,  and  although  this  information  is 
not  currently  exploited,  it  aids  considerably  in  tracing  the  Artist  behaviors. 

When  receiving  the  ROSS  messages 

"display  >type  comm  at  > location" 
or  "display  >type  radar  at  >location" 
or  "display  >  type  burst  at  >  location" 

the  Artist  will  draw  special  symbols  at  the  specified  location  representing  one 
of  these  activities.  For  the  "comm"  request,  the  Artist  will  display  and  then 
automatically  erase  four  concentric  circles  in  an  appropriate  color  to  indicate 
a  tactical  communications  event.  For  the  "radar"  request,  the  Artist  will 


display  an  appropriately  colored  radar  symbol  to  the  left  of  the  location 
specified.  For  the  "burst”  request,  the  Artist  will  display  an  appropriately 
colored  asterisk  to  the  left  of  the  specified  location.  Because  this  depicts  a 
firing  event,  the  symbol  will  be  erased  automatically. 

When  receiving  the  ROSS  message 

"display  >  actor  sensor  coverage" 

the  Artist  will  display  the  particular  sensor's  coverage  area  using  the  sensor's 
range,  current  location,  and  coverage  shape  (circle,  fan,  or  square).  All  of 
these  shapes  are  orange  colored  and  will  be  appropriately  clipped  at  the  edges 
of  the  Ground  Truth  Display. 

When  receiving  the  ROSS  message 

"update  the  clock  to  >  time" 

the  current  value  of  simulation  time  is  displayed  at  the  upper  left  hand  corner 
of  the  screen. 

The  ROSS  message 

"correspond" 

enables  user  interaction  with  the  Ground  Truth  Display  screen  for  information 
query.  The  Artist  initiates  a  dialogue  with  the  user  on  the  text  terminal  of 
the  Controller  Station  concerning  the  objects  on  the  Ground  Truth  Display. 
The  user  may  request  information  about  nodes,  sectors,  threat  units,  and 
sensors,  by  "picking"  them  on  the  graphics  terminal  with  the  cursor.  The 
Artist  will  then  list  on  the  text  terminal  the  full  property  list  for  that  item. 

3.2.4  Node/Node  Environment  File 


The  Node  Environment  file  is  a  file  of  node  instances  created  by  the 
generic  Node  object.  In  this  file  the  individual  node  properties  -  position, 
associated  sector,  node  type  and  linked  neighbor  nodes  -  take  on  specific 
values.  Nodes  do  not  have  behaviors.  They  exist  in  the  current  BEM  as  a 
convenient,  easily  accessible  database.  The  493  node  instances  create  a  node 
network  corresponding  to  the  road  network  depicted  in  the  previous  chapter. 
The  property  "linked-nodes"  is  a  list  of  other  nodes  to  which  there  exists  a 


traffieable  path.  This  information  is  used  by  path  construction  routines  to 
generate  routes  for  the  movement  of  ground  units,  both  threat  and  sensor. 

3.2.5  Pathfinder 

Pathfinder  is  an  auxiliary  object  created  at  the  instance  level.  It  is  used 
both  in  the  preprocessing  of  input  data  and  dynamically  in  the  simulation  to 
find  paths  for  the  Red  units  and  Blue  ground  sensors  over  the  traffic  ability 
network.  The  Pathfinder  accesses  unit  and  network  data  and  determines  a 
time-ordered  route  using  pathfinding  and  other  algorithms  written  in  LISP. 

The  Pathfinder  does  not  have  any  properties  but  has  three  behaviors: 

o  To  determine  a  time-ordered  network  path  for  a  Red  unit 

o  To  determine  a  time-ordered  network  path  for  a  Blue  ground 

sensor 

o  To  move  either  a  sensor  or  unit  over  the  network  path  at  the 
predetermined  times. 

3.2.6  Scheduler 

Scheduler  is  an  auxiliary  object  created  at  the  instance  level.  The 
purpose  of  Scheduler  is  to  create  those  events  which  are  either  of  a  random 
nature  or  would  be  created  by  the  interaction  of  opposing  units  in  a  two-sided 
simulation.  Events  currently  modeled  are  as  follows: 

o  Artillery  fire  missions 

o  Air  defense  engagements 

o  Radar  on-off  status. 

Scheduler  has  the  following  properties  which  control  the  frequency  of  events: 

o  Preparation-frequency,  the  mean  frequency  with  which  artillery 
preparation  fire  missions  are  generated 

o  Fire-mission-frequency,  the  mean  frequency  with  which  artillery 

target -of -opportunity  fire  missions  are  generated 

o  Firing  units,  a  list  of  the  artillery  fire  units  available  depending  on 
the  type  of  mission 


o  Artillery  preparation  start -time,  stop-time  and  length,  set  by  the 

initiating  message 

o  Air  defense  engagement  frequency. 

The  Scheduler  has  eight  behaviors  described  below: 

o  "Initiate  call  for  fire."  This  causes  the  Scheduler  to  take  three 
actions: 

-  schedule  the  next  "initiate  call  for  fire"  according  to  an 
exponentially  distributed  random  variable  time  in  minutes  with 
mean  of  the  fire  mission  frequency 

-  randomly  pick  one  of  the  maneuver  companies  in  contact  to 
call  for  artillery  support 

-  send  a  message  to  that  company  to  make  the  call  for  artillery. 

o  "Cease  call  for  fire."  This  causes  the  Scheduler  to  unplan  its  next 
"initiate  call  for  fire"  and  thereby  terminates  the  cycling  until  it  is 
reinitiated. 

o  "Conduct  >  t-length  minutes  fire  starting  at  time  >t-start."  This 
causes  the  Scheduler  to  set  its  property  values  for  the  preparation 
start-time,  length  and  stop-time  and  to  call  itself  to  "fire  the 
preparation." 

o  "Fire  the  preparation."  Upon  receipt  of  the  message,  the 
Scheduler  takes  the  following  three  actions: 

-  reschedules  the  next  "fire  the  preparation"  message  to  itself 
unless  the  preparation  stop-time  has  been  passed 

-  randomly  picks  an  artillery  battery  which  is  available  to  fire 
(not  moving  or  otherwise  engaged) 

-  sends  a  message  to  the  unit  to  fire. 

o  "Cease  fire  the  preparation."  This  causes  the  Scheduler  to  unplan 
"fire  the  preparation"  and  thereby  stops  the  cycling  of  calls  until 
reinitiated. 

o  "Initiate  Red  radars."  This  causes  the  Scheduler  to 

-  schedule  a  ’^create  air  defense  acquisition"  message  according 
to  an  exponential  distribution  with  a  parameter  of  the  air 
defense  engagement  frequency 


-  schedule  a  duty  cycle  for  each  of  the  various  units  with  radars 
(See  section  3.2.8  for  more  description  of  the  SA-6  acquisition 
sequence). 

o  "Create  air  defense  acquisition."  This  message  causes  the 
Scheduler  to 

-  reschedule  another  "create  air  defense  acquisition"  message  to 
itself 

-  check  each  air  defense  battalion  and  if  one  is  found  that  has  its 
surveillance  radar  on,  the  Scheduler  sends  a  message  to  that 
unit  telling  it  it  has  acquired  a  target. 

o  "Cease  air  defense  acquisition."  This  message  causes  the 

Scheduler  to  unplan  "create  air  defense  acquisition"  and  stops  the 
cycle  until  it  is  reinstated. 

3.2.7  Sector/Sector  Environment  File 

The  Sector  is  an  auxiliary  object  which  performs  two  functions  for  a  BEM 
simulation: 

o  It  acts  as  a  third  party  between  sensors  and  threat  units. 

o  It  can  localize  the  search  for  threat  units  by  some  sensors. 

The  battlefield  is  divided  into  rectangular  sectors  which  do  not  correspond  to 
any  military  sectors.  These  sectors  are  all  created  as  ROSS  instances  and  are 
defined  in  the  Sector  Environment  file.  There  are  no  behaviors  in  this  file; 
the  only  data  slot  is  for  the  position  of  the  sector  instances.  The  position  is 
given  in  the  form  of  four  x-y  locations  of  the  corners  of  the  sector.  Figure  3- 
2  shows  the  allocation  of  sectors  over  the  battlefield  in  the  current  BEM. 

Sector  behaviors  reside  in  the  generic  Sector  actor,  referred  to  as  the 
global  sector  when  the  entire  battlefield  is  treated  as  one  sector.  When  this 
occurs,  the  global  (generic)  sector  acts  as  an  instance  would,  and  messages  are 
sent  directly  to  it  instead  of  the  actual  sector  instances. 

3.2. 7.1  Sector  as  Third  Party.  All  five  sensor  types  use  the  sector  as  a 
third  party  between  them  and  the  threat  units.  This  is  done  to  increase 
the  integrity  of  the  simulation  since  it  is  not  appropriate  to  have  sensors 
accessing  threat  unit  information.  Since  the  sector  can  know  the  dispositions 


of  both  sensors  and  units,  it  acts  to  complete  the  sensor  detection  process 
once  an  initiating  event  has  occurred. 

Table  3-2  shows  the  events  which  trigger  the  detection  process  in 
Sector.  The  occurrence  of  any  of  these  events  results  in  a  corresponding 
message  being  sent  to  either  the  global  sector  or  a  sector  instance.  Thus 
there  are  seven  behaviors  within  Sector. 

The  time  duration  of  events  is  crucial  to  determining  how  the  sensor 
detection  process  works.  Even  though  voice  communications,  artillery  firings, 
and  picture-taking  do  have  time  lengths  associated  with  them,  these  times  are 
considered  small  enough  so  that  the  event  can  essentially  be  considered  to 
occur  at  a  single  point  in  time.  Therefore,  when  voice  communications  occur, 
the  global  sector  will  receive  the  ROSS  message 

"  unit  has  voice  communication  with 
frequency  >  freq  and  duration  >  duration" 
and  when  artillery  or  missile  firings  occur,  the  global  sector  will  receive  the 
message 

"  unit  has  fired  >  artillery-missile". 

The  response  to  these  messages  is  essentially  the  same.  The  Mathematician  is 
asked  to  search  the  list  of  relevant  sensors  in  order  to  determine  time/space 
overlaps  between  sensors  and  units.  For  each  sensor  having  a  time/space 
overlap  with  the  unit,  a  message  will  be  sent  to  it  telling  it  to  "check  for 
sensor  detection..."  This  is  the  essence  of  what  the  Sector  does,  although  the 
time/space  overlap  computations  in  the  Mathematician  vary  widely. 

Sector  responds  to  IMINT  events  upon  receipt  of  the  message 
"  sensor  has  taken  picture  at  >  point" 

The  response  is  similar  to  that  described  above  except  that  in  this  case  the 
sensor  originated  the  event,  and  Sector  will  check  all  units  within  the  relevant 
sensor  coverage  area. 

Because  enemy  anti-aircraft  radars  have  long  duty  cycles  compared  to 
radios  and  because  movement  of  threat  units  through  sectors  is  continuous, 
detection  of  these  events  is  dependent  on  the  time  intersection  between 
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sensor  and  unit  events.  Therefore,  for  these  kinds  of  detections,  the  Sector 
must  respond  to  both  the  threat  unit  event  and  the  sensor  turning  on.  For 
ELINT  detections  the  threat  and  sensor  related  messages  to  Sector  are 
respectively 

"  unit  has  turned  >  type  radar  on  at  frequency  >  freq 
and  duration  >  duration" 

and  "  sensor  has  penetrated  the  sector  with  sensor-data". 

For  MTI  detections  the  threat  and  sensor  related  messages  to  Sector  are 
respectively 

"  unit  has  penetrated  sector  with  >unit-data 
and  "  sensor  has  penetrated  the  sector  with  >  sensor-data". 

Sector  has  four  actor  property  lists  which  relate  to  the  four  messages  above: 
o  Active  -Red-radars 

o  ELINT-sensors 

o  Units 

o  Sensors  (for  MTI). 

Every  time  Sector  receives  one  of  the  four  messages  above,  it  adds  the  threat 
unit  or  sensor  to  its  relevant  property  list  and  plans  to  remove  it  from  the 
property  list  when  that  unit  or  sensor  leaves  the  Sector  (or  stops  moving, 
etc.).  Thus  at  any  given  time,  all  ELINT  and  MTI  sensors  active  in  the  Sector 
and  all  units  which  they  could  detect  are  known  to  the  Sector.  A  time  overlap 
is  simply  that  time  intersection  when  both  sensor  and  unit  are  active  in  the 
Sector.  The  Mathematician  is  asked  to  determine  this  and  for  those 
sensors/units  which  have  time  overlaps,  a  second  check  for  space  overlaps  will 
be  performed.  If  time/space  overlaps  exist,  the  relevant  sensor  will  be 
informed. 

3. 2. 7. 2  Sector  for  Localized  Computation.  The  second  use  of  sectors  is 
for  localization  of  computations.  Because  the  number  of  sensors  and  events 
for  COMINT,  CMCB,  IMINT  and  ELINT  are  relatively  few,  localization  (or  use 
of  the  sector  instances  instead  of  the  global  sector)  is  not  employed  for  these 
sensors.  Only  MTI  sensors  can  use  localization  since  there  are  a  large  number 
of  threat  units  spread  out  over  the  battlefield,  and  most  of  them  are  capable 
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of  movement.  The  idea  behind  localization  is  that  it  is  not  necessary  to  check 
units  over  the  entire  battlefield  if  the  sensor  covers  only  a  small  part  of  it. 
Since  the  sensor  coverage  for  airborne  MTIs  is  extensive,  there  is  no 
advantage  to  using  the  smaller  sectors.  Consequently,  only  ground-based  MTIs 
use  the  smaller  sectors. 

3.2.8  Flightplanner 

Flightplanner  is  an  auxiliary  object  which  constructs  routes  for  the 
airborne  sensors  to  fly.  It  contains  two  behaviors— one  which  constructs  a 
racetrack  pattern  and  the  other  which  constructs  a  route  based  on  a  list  of 
arbitrarily  specified  points  (used  only  for  IMINT  sensors).  The  relevant  ROSS 
messages  to  which  the  Flightplanner  responds  are,  respectively: 

"move  airborne  sensor  >sensor  using  racetrack  pattern" 
and  "move  airborne  imint  sensor  >  sensor  along  points >  points". 

For  the  racetrack  pattern,  information  relating  to  the  leg  length,  number 
of  times  around,  and  initial  point  have  been  placed  in  the  sensor's  "plan" 
property.  This  plan  will  be  reworked  to  form  a  list  of  points  and  associated 
times  which  establish  a  template  for  the  racetrack  pattern.  The  first  and  last 
points  on  the  route  are  the  airport.  The  initial  timing  of  the  route  is  set  so 
that  an  aircraft  takes  off  as  soon  as  possible,  i.e.,  after  an  appropriate 
response  delay.  The  initial  point  is  the  lower  right  hand  point  of  the  racetrack 
pattern.  A  total  of  six  points  will  be  calculated  based  on  the  initial  point,  and 
associated  times  will  be  calculated  using  the  speed  of  the  aircraft.  The 
aircraft  always  flies  around  the  racetrack  in  a  counterclockwise  direction. 
Figure  3-3  shows  the  route  constructed  for  an  example  sensor  with  a  fan¬ 
shaped  coverage  area.  For  the  template  points  on  revolutions  beyond  the 
first,  times  will  simply  be  updated  with  the  time  it  takes  to  make  a  complete 
circuit  of  the  racetrack  pattern.  When  the  template  plan  is  finished, 
Mathematician  is  asked  to  "calculate  update  points  for  isensor".  This 
process  will  generate  intermediate  points  according  to  the  resolution  specified 
by  the  user  for  use  with  the  graphics  displays  of  the  Ground  Truth  and  Sensor 
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Control  stations.  This  updated  plan  is  stored  back  into  the  "plan"  property  of 
the  sensor. 

The  routes  for  I  MINT  sensors  are  constructed  from  the  list  of  points 
passed  in  the  message.  Times  at  these  points  are  calculated  using  the 
aircraft's  speed  and,  as  before,  Mathematician  is  asked  to  refine  the  route  by 
calculating  intermediate  times  and  points. 

3.2.9  Mathematician 

The  Mathematician  is  an  auxiliary  object  which  serves  the  computational 
needs  of  the  other  objects. 

The  twelve  behaviors  of  the  Mathematician  are  divided  into  three 
categories: 

o  Determination  of  time/space  overlaps 

o  Calculation  of  sector  penetrations  by  units  and  sensors 

o  Refining  stored  data. 

The  determination  of  time  and  space  overlaps  was  first  described  in  the 
section  on  the  actor  Sector.  The  messages  are  all  of  the  general  form 
"determine  time/space  overlap  between  >  a  and  >  b,"  where  "a"  is  a  sensor, 
and  "b"  denotes  the  list  of  relevant  units  to  be  searched.  If  the  event  is  a  type 
that  has  no  time  duration  (as  discussed  in  Section  3.2.7),  a  simple 
determination  of  space  overlap  will  be  made  which  entails  calculating  whether 
a  unit  is  within  a  sensor's  coverage  area  at  the  given  time.  If  the  event  has 
significant  time  duration,  a  calculation  will  first  be  made  to  determine  the 
time  overlap.  A  time  overlap  is  simply  the  intersection  of  the  time  intervals 
of  the  unit  and  the  sensor  within  the  sector.  Using  lower-level  LISP  routines, 
further  calculations  are  made  to  determine  if  there  was  a  space  overlap 
within  that  time  overlap. 

The  second  major  function  of  the  Mathematician  is  the  calculation  of 
sector  penetrations  by  sensors  and  units.  For  sensors,  penetration  applies  not 
to  the  sensor  itself  but  to  its  coverage  area.  A  sensor  coverage  area 
"penetrates"  a  sector  either  when  the  sensor  first  turns  on  or  during 
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movement  when  the  coverage  area  first  intersects  a  sector  boundary,  and 
when  the  sensor  coverage  area  exits  the  sector.  In  the  case  of  units,  sector 
penetration  means  movement  of  the  unit  both  into  and  out  of  the  sector.  If 
the  unit  was  already  in  a  sector  and  not  moving,  the  initiation  of  its 
movement  would  constitute  a  sector  penetration. 

Finally,  the  Mathematician  can  refine  existing  data.  One  method, 
discussed  in  Section  3.2.8,  was  the  calculation  of  intermediate  time  and 
position  points  for  a  more  roughly  laid  out  plan.  These  calculations  are  done 
solely  to  smooth  out  sensor  and  unit  movement  on  the  graphics  displays.  A 
second  form  of  data  refinement  occurs  when  the  Mathematician  receives  the 
message: 

"reconstruct  cycle  definition  for  >  object". 

It  then  takes  information  on  a  sensor's  mission  start-time,  mission  duration, 
and  duty  cycle  and  creates  a  list  of  sublists  which  contain  on/off  times  for  the 
entire  duration  of  the  mission.  The  information,  put  in  this  form,  is  used  by  a 
variety  of  other  actors. 

3.2.10  Interface 

Interface  is  an  auxiliary  object  which  acts  on  messages  from  the  sensor 

actors  (MTI,  COMINT,  CMCB,  ELINT,  IMINT)  to  the  effect  that  a  specified 
unit  has  been  detected.  The  messages  coming  from  the  five  sensors  are: 

"mti  > sensor  has  detected  >unit" 

'feomint  >  sensor  has  detected  >  unit  at  frequency  >  freq  and 

duration  duration" 

'temcb  >  sensor  has  detected  >  unit" 

"elint  >  sensor  has  detected  >unit  of  type  >  type  and 
frequency  >freq" 

"imint  >  sensor  has  detected  >unit  at  time  >time". 

Some  of  these  messages  pass  variables  relating  to  frequency  or  duration 
since  these  can  only  be  known  at  the  time  a  unit  initiated  the  event  resulting 
in  its  detection.  Interface  exists  to  combine  these  data  with  other  types  of 
data  stored  in  the  threat  units'  data  base.  The  information  will  be  formatted 
into  a  sensor  report  which  contains  only  that  information  which  that  sensor 
could  reasonably  detect.  Sensor  reports  are  accumulated  and  sent  out  to  the 


ANALYST  and/or  Blue  Sensor  Control  Station  by  the  Simulator  at  a  frequency 
related  to  the  simulation  clock  step  size. 

3.2.11  Unit 

Unit  is  a  high-level  generic  actor  with  few  assigned  property  values  but 
which  has  most  of  the  behaviors  presently  provided  to  any  of  the  Red  units  in 
the  simulation.  Its  parent  in  the  object  hierarchy  is  the  generic  actor 
Simulator,  its  subordinates  are  Action-Unit  and  Control-Unit.  The  other 
property  slots  which  are  assigned  values  are  times  such  as  communication 
delay  time,  response  delay,  fire  mission  call  time  and  other  lengths  of 
communications. 

There  are  five  unit  behaviors  stored  at  this  level  of  the  actor  hierarchy. 
These  are  behaviors  in  response  to  the  following  messages: 

o  "Proceed  to >  position".  This  causes  the  unit  to  take  the  following 

actions: 

-  notify  the  Artist  to  move  the  unit  position  on  the  Ground  Truth 
Display 

-  set  the  unit  position  to  the  next  position 

-  shut  down  its  surveillance  radar  if  it  has  one 

-  set  the  unit  activity  to  moving. 

o  "Move  according  to  plan."  This  causes  the  unit  to  take  the 

following  action: 

-  notify  the  Artist  to  display  a  confirmation  communications  call 

-  notify  the  Sector  of  the  communications  call 

-  request  the  Pathfinder  to  move  the  unit  from  its  present 
position  to  its  destination. 

o  "Have  arrived  at  node  > node."  This  causes  the  unit  to  take  the 

following  actions: 

-  notify  the  Artist  to  display  a  control  call  communication 

-  notify  the  Sector  that  a  voice  communication  has  been  made  and 
letting  it  know  of  the  radio  frequency  and  length  of  call. 


o  "Have  arrived  at  final  destination."  This  causes  the  unit  to  take 
the  following  action: 

-  notify  the  Artist  to  display  a  closing  call  communication 

-  notify  the  Sector  of  the  communication,  frequency  and 
directives 

-  set  its  activity  to  "in-position" 

-  send  a  message  to  Scheduler  to  begin  recycling  of  the  units 
radar  if  it  has  a  surveillance  radar. 

o  "Turn  >type  radar  >onoff."  If  the  unit  is  moving,  then  it  sets  its 

radar  status  to  off,  unplans  any  future  planned  radar  cycle,  and 
tells  the  Scheduler  to  unplan  any  cycling.  If  the  unit  is  not  moving 
and  the  message  is  to  turn  the  radar  type  on,  then  it  takes  the 
following  actions: 

-  notifies  the  Artist  to  display  the  radar  symbol 

-  notifies  the  Sector  that  the  radar  has  been  turned  on  and  states 
the  frequency  and  duration 

-  sets  the  radar  status  to  on. 

If  the  unit  is  not  moving  and  the  message  is  to  turn  the  radar  off,  then 
the  unit  makes  the  notifications  to  the  Artist  and  Sector  and  sets  its  radar 
status  to  off. 

3.2.12  Control-Unit 

Control-Unit  is  the  generic  actor  from  which  all  the  control  units  (i.e., 
those  with  subordinates  in  the  military  hierarchy)  stem.  The  actor  parent  of 
Control-Unit  is  the  generic  actor  Unit,  while  the  subordinates  are  the  types  of 
control  units,  e.g.,  tank  battalion  headquarters,  tank  regiment  headquarters, 
division  headquarters. 

The  properties  for  the  Control-Unit  are  inherited  from  its  parent,  Unit. 
Control-Unit  has  four  behaviors.  The  first  is  for  all  control  units;  the  second 
is  for  maneuver  (tank  or  motorized  rifle)  battalion  headquarters;  the  third  and 
fourth  are  for  an  air  defense  regimental  headquarters. 

o  "Implement  battle  plans."  This  message  comes  initially  from  the 
simulation  scenario  to  the  division  headquarters  and  is  passed  on  through 
the  military  chain  of  command  until  reaching  the  resolution  level,  the 
individual  companies  in  the  simulation.  On  receipt  of  the  message, 
Control  Units  take  the  following  actions: 


issue  a  confirmation  cedi  acknowledging  receipt  of  the  message 

issue  a  communication  call  to  each  of  its  subordinates  to 
"implement  the  battle  plan" 

notify  both  the  Artist  and  the  Sector  of  the  above  communication 

ask  Pathfinder  to  move  the  unit  according  to  its  pre-arranged 
movement  plan. 

The  behavior  for  the  maneuver  battalion  command  observation  post 
(COP)  is  in  response  to  the  message  "request  fire  support"  from  one  of  the 
subordinate  companies.  This  simulates  the  joint  effort  of  the  maneuver 
battalion  and  the  collocated  artillery  representative.  The  actions  taken  are  as 
follows: 

o  A  communication  is  made  acknowledging  receipt  of  the  message,  and 
the  Artist  and  Sector  are  notified  accordingly. 

o  A  check  is  made  of  the  artillery  battalions  available  to  support  that 
maneuver  unit;  the  artillery  must  be  within  range  to  provide  support, 
and  must  not  be  moving  or  already  engaged  in  firing. 

o  The  number  of  volleys  of  fire  needed  for  the  target  is  generated  using  a 
Poisson  distribution;  this  determines  both  the  number  of  communications 
to  the  firing  unit  for  adjusted  fire  and  the  number  of  firings  by  the 
artillery  unit  for  that  mission. 

o  The  Artist  and  Sector  are  notified  of  the  communications  calling  this 
artillery  unit  to  fire. 

The  first  behavior  for  the  air  defense  regimental  headquarters  is  in 

response  to  the  message  "target  acquired"  which  is  generated  by  the  Scheduler 
to  simulate  an  airborne  target  being  detected  by  the  regiment  surveillance 
radars.  The  following  actions  are  taken: 

o  the  regiment  headquarters  turns  its  heightfinder  radar  on  and  notifies 
the  Artist  and  Sector  accordingly 

o  the  regiment  headquarters  picks  one  of  its  batteries  to  engage  the 
target,  the  battery  must  not  be  moving  or  already  engaged  in  firing 

o  a  communication  is  made  to  the  battery  to  "engage  the  target"  and  the 
Artist  and  Sector  are  notified  accordingly. 


The  second  behavior  for  the  air  defense  regiment  headquarters  is  in 
response  to  the  message  "mission  complete"  when  it  receives  a  message  from 
one  of  its  batteries  that  a  mission  has  been  completed.  The  following  actions 
are  taken: 

o  The  headquarters  issues  a  communication  acknowledging  receipt  of  the 
call  and  notifies  the  Artist  and  Sector  accordingly 

o  The  headquarters  sends  a  message  to  itself  to  turn  off  its  heightfinder 
radar. 

3.2.13  Action  Unit 

Action-Unit  is  the  generic  actor  from  which  all  the  company  level  units 
(those  without  subordinates)  stem.  The  actor  parent  of  Action  Unit  is  the 
generic  actor  Unit;  the  subordinates  are  the  types  of  action  units,  that  is,  the 
generic  company  level  units. 

Five  behaviors  are  stored  with  Action  Unit.  The  first  deals  with  the 
battle  plan  implementation  and  is  used  by  all  action  units;  the  second  is  for 
maneuver  companies  requesting  artillery  support,  the  third  is  for  the  artillery 
batteries  providing  the  fire  support,  the  fourth  is  for  air  defense  batteries 
engaging  a  target,  and  the  fifth  is  for  artillery  units  firing  preparatory  fires. 

The  message  "implement  battle  plan"  is  received  from  the  units  military 
superior  and,  if  the  unit  is  scheduled  to  move  during  the  time  slice,  the 
Pathfinder  is  asked  to  move  the  unit  according  to  the  plan,  on  the  units 
property  list. 

A  maneuver  unit  in  contact  may  receive  a  message  "call  for  fire"  from 
the  Scheduler  telling  it  to  call  for  fire  support  as  if  the  unit  were  engaging  an 
enemy  target.  The  unit  sends  a  communication  to  its  battalion  headquarters 
requesting  artillery  support;  the  Artist  and  Sector  are  notified  of  this 
communication. 

A  behavior  for  an  artillery  battery  is  in  response  to  the  message  "fire 
mission"  which  it  may  receive  several  times,  simulating  additional  calls  to 
adjust  effects  on  the  target.  The  following  actions  are  taken: 


o  The  Artist  and  Sector  are  notified  of  the  communication  call 
acknowledging  receipt  of  the  message. 

o  The  Artist  and  Sector  are  notified  of  the  firing. 

o  The  unit  sets  its  activity  to  firing  and  then  "in  position"  at  the  end  of 
the  mission. 

The  behavior  for  the  air  defense  battery  is  in  response  to  the  message 
"engage  the  target"  which  it  receives  from  the  regiment  headquarters.  The 
following  actions  are  taken: 

o  The  Artist  and  Sector  are  notified  of  the  communication  acknowledging 
receipt  of  the  message. 

o  The  Artist  and  Sector  are  notified  of  each  time  an  air  defense  missile  is 
fired. 

o  The  unit  sets  its  activity  to  "firing"  during  the  mission  and  to  "in 
position"  after  completion  of  the  mission. 

o  The  number  of  missiles  which  the  unit  fires  is  determined  according  to  a 
Poisson  distribution. 

o  A  communication  is  made  to  the  regiment  headquarters  on  mission 

completion,  and  the  Artist  and  Sector  are  notified  of  this  this 
communication. 

The  other  behavior  for  artillery  batteries  is  in  response  to  the  message 
"fire  preparatory  fires"  which  it  receives  from  Scheduler.  The  following 
actions  are  taken: 

o  The  unit  sets  its  activity  to  "firing". 


o  The  unit  notifies  Artist  and  Sector  of  the  firing, 
o  The  unit  sets  it  activity  to  "in  position"  at  the  mission  completion. 

3.2.14  Unit  Property  File 

This  file  contains  the  generic  unit  property  data,  that  is,  each  of  the 
actors  just  above  the  instance  level.  There  are  forty  generic  units  currently 
in  the  BEM.  These  include  the  combat,  combat  support  and  combat  service 
support  units  at  company  level  and  their  headquarters  from  battalion  to 
division  level.  The  parent  of  each  of  the  action  units,  i.e.,  those  at  company 


level,  is  the  generic  actor  Action-Unit.  The  parent  of  each  of  the  control 
units,  i.e.,  the  headquarters  units,  is  the  generic  actor  Control-Unit. 

Properties  for  the  generic  units  include  the  parent  unit,  offspring  units, 
numbers  and  types  of  vehicles,  types  of  radios,  radio  networks  used,  times  to 
clear  from  and  close  into  position,  convoy  speed  and  convoy  length.  (See 
Appendix  in.) 

No  actor  behaviors  are  currently  stored  at  this  level. 

3.2.15  Red  Instance  File 

This  file  contains  the  instantiation  of  each  of  the  144  basic  actors 
representing  the  Red  units  in  the  simulation.  The  actor  parents  are  the 
generic  units  described  in  the  above  paragraph.  The  instance  actors  do  not 
have  offspring  in  the  actor  hierarchy.  No  behaviors  are  currently  stored  at 
this  level. 

It  is  at  this  level  that  the  unit  receives  its  individual  properties.  These 
include  the  starting  and  final  location  for  the  unit  in  the  time  slice;  the  unit's 
location  in  the  military  hierarchy  to  include  superior  unit,  subordinate  units, 
supporting  artillery  units,  units  supported,  combat  service  support  units  and 
alternate  headquarters.  Additional  properties  include  the  radio  frequencies  on 
which  the  unit  operates  in  order  to  communicate  with  superior,  subordinate 
and  supporting  units. 

3.2.16  Sensor 

The  generic  object  "Sensor"  is  the  highest  level  object  pertaining  to 
sensors.  It  contains  a  property  list  as  a  template  for  lower-level  sensor 
objects.  The  values  of  the  elements  of  the  property  list  are  mostly  unfilled  at 
this  level.  The  Sensor  has  only  one  behavior  and  that  is  related  to 
movement.  Its  response  to  the  message 

"proceed  to  <  position" 

is  to  ask  the  Artist  to  move  a  sensor  instance  from  its  current  position  to  the 
position  specified  and  then  to  update  the  property  "position"  to  the  new 
location. 


3.2.17  Sensor-Control-Unit 

The  generic  object  "Sensor-Control-Unit"  contains  the  behavioral 
responses  to  the  initial  tasking  of  ground  or  air  sensors.  Thus,  in  response  to  a 
message 

"send  ground  >  type  sensor  to  setup  point  >  setup-pt 
for  > mission-duration  minute  mission" 

a  sensor  control  unit  will  find  a  ground  sensor  of  the  type  required  by  checking 
through  the  list  of  sensors  assigned  to  it  until  it  finds  one  not  currently 
tasked.  Then  a  timing  task  will  be  constructed  containing  information  related 
to  the  mission  duration  and  duty  cycle  (if  pertinent).  A  message  will  then  be 
sent  to  the  selected  ground  sensor  ordering  it  to  move  to  the  specified  setup 
point  and  to  start  its  mission  according  to  the  constructed  task.  Had  no 
ground  sensor  of  the  required  type  been  available,  the  request  would  have 
been  discarded  with  an  appropriate  response  sent  to  the  user  via  the  text 
terminal  of  the  BEM  Controller  Station. 

For  airborne  sensors,  the  sensor,  control  unit  would  receive  a  message  of 
the  form 

"send  up  airborne  >type  sensor  in  >leg-length  Km 
racetrack  pattern  >num-circuits  times  around  with 
initial  pt  >init-pt" 

and  search  for  and  select  the  appropriate  sensor  in  the  way  it  did  for  ground 
sensors.  The  variable  information  passed  in  the  message  —  the  type  of  sensor, 
the  leg  length  of  the  racetrack  pattern,  the  number  of  circuits  around  the 
racetrack  and  the  initial  point  of  the  racetrack  —  are  sufficient  to  completely 
describe  the  activities  of  the  sensor  chosen.  Again  a  message  will  be  sent  to 
the  selected  sensor  passing  timing  and  route  information  in  a  structured 
format. 

A  separate  behavior  exists  for  airborne  IMINT  (Photo)  sensors  since  their 
behaviors  are  significantly  different  from  other  airborne  sensors.  Airborne 
IMINT  sensors  travel  to  specified  points  to  take  photographs  instead  of 
following  a  racetrack  pattern.  However,  the  behaviors  for  selecting  a  sensor, 


sending  a  sensor  an  order  to  move,  and  responding  if  no  sensor  is  available  are 
the  same  as  for  other  sensors. 

3.2.18  Sensor- Action-Unit 

The  Sensor-Action-Unit  is  a  generic  object  which  contains  some  of  the 
behavioral  responses  to  the  messages  sent  by  a  sensor  control  unit.  The 
behavior  involved  with  moving  an  airborne  IMINT  sensor  applies  only  to  IMINT 
sensors  and  is  therefore  appropriately  placed  in  the  generic  IMINT  actor,  one 
level  down  from  the  Sensor-Action-Unit. 

Upon  receipt  of  the  ROSS  message 

"move  ground  sensor  to  >  point  with  >task" 
the  Sensor-Action-Unit  will  ask  the  Artist  to  draw  the  sensor  on  the  Ground 
Truth  Display  at  its  initial  position.  The  Artist  will  also  be  asked  to  draw  and 
erase  the  sensor's  coverage  area  periodically  according  to  its  duty  cycle.  If 
the  ground  sensor  is  to  be  moved,  a  message  will  be  sent  to  the  Pathfinder 
actor  asking  it  to  construct  for  the  sensor  a  route  over  the  road  network.  The 
sensor  will  be  placed  on  a  list  of  "sensors-in-use"  so  that  it  cannot  be  retasked 
during  its  mission.  If  the  sensor  is  an  MTI,  a  message  is  sent  to  the 
Mathematician  actor  asking  it  to  determine  when  the  sector(s)  are  penetrated, 
i.e.,  when  the  sensor  turns  on  and  off.  Information  pertaining  to  the  on/off 
status  of  the  sensor  will  be  sent  to  the  Blue  Sensor  Control  Station  (BSCS)  if  it 
is  turned  on  so  that  the  appropriate  sensor  coverage  may  be  displayed  on  the 
BSCS  graphics  terminal. 

Another  behavior  in  the  Sensor-Action-Unit  responds  to  the  ROSS 
m  essage 

"move  airborne  sensor  in  racetrack  pattern  with  >  task 

and  >  plan." 

Again  the  Artist  will  be  sent  a  message  to  display  the  airborne  sensor  at  its 
initial  position  (always  an  airport).  The  Flightplanner  actor  will  be  asked  to 
construct  an  airborne  route  for  the  sensor.  If  the  sensor  uses  sectors  directly 
to  help  with  detection,  Mathematician  will  be  asked  to  determine  when  the 


sensor's  coverage  "penetrates"  the  relevant  sector(s).The  only  other  bet 
of  the  Sensor- Action-Unit  responds  to  is  the  message 

"fly  to  >  position." 

A  sequence  of  these  messages  are  created  as  a  result  of  the  route  const) 
by  the  Flightplanner  and  refined  by  the  Mathematician.  The  response  i 
message  principally  involves  updating  current  position  of  the  Sense 
asking  the  Artist  to  display  the  movement  of  both  the  sensor  and  its  re 
coverage  area.  Since  airborne  sensors  turn  their  coverage  off  as  they  t 
their  racetrack  pattern,  the  on  and  off  status  of  the  sensor  will  a 
reflected  by  those  same  messages  to  Artist.  Finally,  the  current  positi 
on/off  status  of  the  sensor  will  be  sent  to  the  Blue  Sensor  Control  Stal 
that  it  may  display  the  sensor's  movement  and  coverage  on  its  own  gr 
terminal.  Thus  the  sensor  will  be  seen  moving  on  both  the  Ground  Tru 
BSCS  displays. 

3.2.19  Generic  Sensors 

There  are  five  generic  sensor  actors  —  MTI,  COMINT,  CMCB,  ELIf 
IMINT  —  all  of  which  are  created  by  the  Sensor-Action-Unit.  As 
previously,  there  are  currently  no  formal  sensor  models  in  the  BEM 
detections  based  on  an  event  occurring  within  the  geographic  coverage  e 
the  sensor.  When  that  detection  occurs,  a  message  is  sent  by  the  Sector 
(acting  as  an  intermediary  between  threat  and  sensor  units)  to  the 
involved  asking  it  to 

'V;heck  sensor  detection  of  >  unit." 

Currently  the  sole  response  of  all  sensors  is  to  consider  the  specified  i 
be  detected  upon  receipt  of  this  message  and  to  cause  a  sensor  report 
sent  out  to  ANALYST  or  the  Blue  Sensor  Control  Station  by  sending  a  m 
to  the  BEM  actor  Interface.  In  a  future  version  of  the  BEM,  formal 
models  will  reside  in  the  generic  sensor  actors  and  will  make  a  I 
determination  based  on  terrain,  signal  attenuation,  etc.  as  to  wheth 
observable  was  actually  detected. 


The  generic  IMINT  actor,  however,  has  otner  behaviors  not  related  to 
sensor  detection  but  to  sensor  movement.  These  are  behaviors  associated 
with  the  "move"  and  "fly  to"  messages  first  discussed  in  the  previous  section 
on  the  Sensor-Action-Unit.  Although  the  movement  of  airborne  IMINT  sensors 
is  different  from  the  racetrack  patterns  of  other  airborne  sensors,  the 
response  to  these  messages  is  functionally  equivalent  to  the  corresponding 
behaviors  in  the  Sensor- Action-Unit. 

3.2.20  Sensor  Instance  File 

The  sensor  instance  file  contains  the  ROSS  instances  for  the  sensor 
control  unit  and  all  sensors  used  in  the  BEM  simulation.  There  are  no 
behaviors  in  this  file,  only  properties  relating  to  sensor  range,  coverage, 
speed,  type,  and  beginning  and  ending  points.  This  file  contains  all  sensors 
known  to  the  BEM  although  they  need  not  all  be  tasked  by  the  Scenario  actor 
during  the  running  of  a  simulation.  By  keeping  a  group  of  sensors  in  reserve, 
there  are  always  some  available  for  dynamic  tasking  from  the  Blue  Sensor 
Control  Station. 

3.3  Considerations  For  Using  ROSS/LISP 

The  use  of  the  ROSS  programming  language  is  a  very  positive  feature  of 
the  current  BEM.  Even  though  a  message-passing  environment  is  radically 
different  from  the  standard  procedural  environment,  acclimation  to  it  is  fast 
and  easy.  The  use  of  object-oriented  programming  techniques  is  most 
advantageous  at  the  command  and  control  level.  At  this  high  level,  the  ROSS 
messages  and  objects  closely  conform  to  actual  communications  between  real- 
world  actors.  This  is  true  for  both  threat  units  and  sensors.  However,  at  a 
somewhat  lower  level,  where  auxiliary  actors  and  their  messages  have  perhaps 
no  real-world  counterparts,  the  inherent  modularity  of  ROSS  code  can  still 
enhance  the  intelligibility  of  many  processes.  It  is  at  the  very  low  levels, 
usually  involving  computational  processes,  that  the  efficacy  of  message 
passing  breaks  down.  There  is  an  overhead  attached  to  processing  messages; 
therefore,  the  point  at  which  message  passing  no  longer  clarifies  a  process  is 
the  point  at  which  it  should  be  abandoned  in  favor  of  LISP  function  calls. 
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Determining  where  this  point  is,  however,  is  largely  judgmental,  and 
can  even  be  a  matter  of  style.  Many  computational  processes  which  might 
otherwise  have  been  placed  in  the  Mathematician  exist  instead  in  pure  LISP 
functions.  Placing  a  computation  in  the  Mathematician  means  that  it  will  be 
performed  as  a  result  of  a  message  sent  instead  of  a  LISP  function  call.  The 
decision  as  to  which  processes  to  single  out  in  this  manner  is  largely 
judgmental  and  related  to  a  sense  of  aesthetics  and  whether  the  implementor 
thinks  that  an  English-worded  ROSS  message  adds  something  to  the 
understanding  of  the  simulation. 

Another  consideration  in  the  use  of  ROSS/LISP  is  the  resulting 
development  and  demonstration  environments.  For  small  programs,  use  of  the 
interpreter  is  a  productive  method  for  constructing  and  debugging.  The 
process  of  compiling  ROSS  code  is  not  fast  and  the  compiler  still  has  some 
vagaries  attached  to  its  use.  However,  as  the  BEM  has  grown  larger,  it  has 
been  necessary  to  run  a  good  portion  of  the  code  compiled  even  when 
debugging.  For  demonstrations,  even  though  almost  all  code  is  compiled,  the 
BEM  simulation  may  run  at  best  with  a  simulation  to  real  time  ratio  of  2:1  or 
3:1.  For  many  uses  this  is  not  undesirable,  but  as  the  BEM  continues  to  grow, 
speeds  less  than  this  would  be  unacceptable. 
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4.0  FUTURE  ENHANCEMENTS  OF  THE  BEM 


Work  has  already  begun  on  what  is  tentatively  called  BEM  n.  Whereas 
the  current  BEM  models  the  activities  of  a  Soviet  division  with  company-level 
resolution,  BEM  n  will  model  echelons  above  corps  with  battalion-level 
resolution.  Some  other  areas  of  future  development  which  will  be  discussed  in 
the  following  sections  are: 
o  formal  sensor  models 

o  two-sided  simulation 

o  speed-up  of  processing. 

4.1  Formal  Sensor  Models 

As  was  emphasized  in  the  previous  section  on  Generic  Sensors  (Section 
3.2.15),  the  BEM  models  sensor  detection  of  threat  units  by  determining 
whether  a  unit  or  unit  activity  lies  within  a  relevant  sensor's  coverage  area. 
This  is  essentially  a  first  step  in  the  total  process  of  detecting  units.  The 
second  step  involves  the  use  of  formal  sensor  models  which  are  not  now 
present  in  the  BEM.  In  the  future,  detection  "candidates"  from  the  first  step 
may  be  presented  to  these  formal  sensor  models  which  use  additional  criteria 
to  determine  whether  or  not  a  detection  has  occurred.  Factors  such  as 
terrain,  signal  attenuation,  weather,  and  sensor  errors  can  all  be  considered  in 
the  design  of  formal  sensor  models.  In  addition,  various  approaches  to 
modeling  multiple  sensors  on  a  single  platform  will  be  considered.  More 
detailed  and  realistic  modeling  of  sensors  must  be  considered  in  a  future  BEM 
if  it  is  to  become  a  useful  testbed  for  sensor  deployment  studies. 

4.2  Two-Sided  Simulation 

The  current  BEM  is  one-sided,  i.e.,  there  is  no  modeling  of  Blue  (NATO) 
forces  other  than  sensors.  Consequently,  somewhat  artificial  means  (random 
generators)  are  used  to  cause  Soviet  radar  emissions  and  artillery  firings, 
etc.  In  a  two-sided  model,  these  events  would  most  likely  stem  from  a 
reaction  to  Blue  force  actions.  It  is  therefore  desirable  to  create  a 
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representation  of  the  Blue  force  side  (other  than  sensors)  so  that  the  BEM  can 
further  serve  as  a  testbed  for  command  and  control  studies. 

4.3  Speed-Up  Of  Processing 

The  current  speed  limitations  of  the  BEM  were  discussed  in  Section  3.3. 
The  BEM  simulation  runs  slowest,  of  course,  when  all  three  components  of  a 
demonstration  are  active  —  the  ANALYST,  the  Blue  Sensor  Control  Station, 
and  the  BEM  proper.  The  ANALYST  currently  runs  during  a  demonstration  on 
the  VAX  11/780.  When  the  VAX  and  the  SPL's  LISP  machine  are  linked 
together,  the  ANALYST  will  run  on  the  LISP  machine,  thus  removing  a 
significant  computational  burden  from  the  VAX.  The  Blue  Sensor  Control 
Station  can  relieve  some  of  the  computational  burden  by  not  only  undergoing  a 
careful  adjustment  of  its  priorities,  but  also  a  restructuring  of  its  menuing  to 
a  non-cursor  mode.  In  the  BEM  proper,  many  computations  regarding  threat 
movement  are  currently  preprocessed  since  that  movement  is  determined 
from  the  SCORES  data.  Some  subsequent  computations  related  to  this 
movement  are  currently  performed  during  the  simulation,  but  could  also  be 
preprocessed.  With  these  changes  and  a  more  careful  look  at  ways  to 
optimize  the  modeling  effort,  the  BEM  II  should  be  able  to  maintain  an 
acceptable  running  time. 


TABLE  OF  CONTENTS 


1.0  INTRODUCTION 
2.0  SENSOR  DATA 

2.1  Sensor  Employment 


2.1.1.  SIGINT  Employment 

2.1.2  MTI  Employment 

2.1.3  CM/CB  Employment 

2.1.4  IMINT  Employment 

2.2  Sensor  Properties 


3.0  FUTURE  EFFORTS 

3.1  Data  for  Formal  Sensor  Models 

3.2  Message  Formats 


REFERENCES 


1.0  INTRODUCTION 


The  purpose  of  this  appendix  is  to  describe  the  research  that  has  been 
done  so  far  on  U.S.  sensors  for  use  in  the  Battlefield  Environment  Model 
(BEM).  This  research  covered  two  aspects  of  sensors  -  employment  methods 
and  properties;  the  generic  sensor  types  discussed  are  SIGINT  (COMINT  and 
ELINT),  MTI,  CM/CB,  and  IMINT;  jammers  are  not  included  now,  although 
they  will  be  in  the  future. 

The  research  was  conducted  mainly  by  consulting  personnel  at  the  Signals 
Warfare  Lab  (SWL)  1,  the  MITRE  Corporation3,  and  DIA3,  as  well  as  the 
referenced  documents. 
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2.0  SENSOR  DATA 


This  section  begins  with  a  brief  discussion  of  the  employment  of  each 
generic  sensor  type  which  is  now  modeled  in  the  BEM  or  is  intended  to  be 
modeled  in  the  near  future;  this  discussion  is  followed  by  a  listing  of  the 
properties  for  each  type,  in  chart  form.  The  information  is  what  was 
necessary  to  support  the  determination  of  time-and-space  overlaps  of  sensors 
and  units  used  in  the  initial  modeling  effort;  see  Section  3.1  for  more 
extensive  sensor  parameters  to  be  used  later  in  the  formal  sensor  models. 

2.1  Sensor  Employment 

2.1.1  SIGINT  Employment 

Difficulties  in  modeling  IEW  are  caused  by  the  fact  that  our  current  IEW 
technology  has  not  been  tested  in  actual  combat;  therefore  there  are  no  firm 
and  precise  procedural  guidelines  for  performing  IEW  functions.  What  follows 
is  a  general  description  of  those  aspects  of  SIGINT  sensor  employment  to  be 
modeled  in  the  BEM  and  our  current  understanding  of  the  procedures  that  will 
ultimately  be  used. 

For  our  purposes,  SIGINT  (Signals  Intelligence)  will  be  considered  to  be 
performed  by  COMINT  (Communications  Intelligence)  and  ELINT  (Electronic 
Intelligence)  sensors.  COMINT  sensors  are  intended  to  intercept  and  locate 
emissions  from  enemy  radios  (current  model  requirements  deal  only  with 
COMINT  externals);  ELINT  sensors  perform  a  similar  function  on  enemy  radar 
emissions. 

COMINT  and  ELINT  sensors  are  combined  here  because  they  involve 
similar  employment  techniques;  however,  their  properties  differ  enough  to 
warrant  separate  representation  in  the  model. 

For  purposes  of  discussion,  the  basic  functions  of  COMINT  and  ELINT 
sensors  are  divided  into  three  processes  —  tasking,  collection,  and  reporting. 


Mission  tasking  for  these  sensors  comes  from  the  S2/TCAE  at  the  CEWI 
Group  (corps  echelon)  or  CEWI  BN  (division  echelon).  Tasking  can  include: 

o  mission  start  and  end  time 

o  location  of  sensors  -  For  airborne  sensors  this  could  be  instructions 
to  proceed  to  point  A  and  begin  flying  an  ellipse  around  points  A  and 
B. 

o  targets  -  This  may  be  a  list  of  frequencies  to  scan  a  specified  target 
type,  such  as  "all  artillery  battalion  command  posts,"  or  instructions 
to  collect  against  any  emitters  for  which  the  sensor  has  the 
capability  in  a  given  geographical  area. 

Collection 

When  tasking  is  received,  the  sensors  will  move  into  position  and  begin 
collecting.  They  will  be  shown  moving  within  their  respective  areas  — 
division  for  rotary  wing  and  some  ground  sensors,  corps  for  fixed-wing  and 
some  ground  sensors. 

Since  COMINT  and  ELINT  sensors  are  passive  and  not  easily  subject  to 
detection  by  the  enemy,  the  sensors  can  be  on  for  the  duration  of  the  mission, 
less  travel  time  to  and  from  position.  However,  any  data  links  from  the 
sensor  platform  are  detectable,  and  are  always  on  when  there  is  no  operator  in 
the  aircraft.  When  there  is  an  operator  in  the  aircraft,  he  can  report  signals 
as  they  are  intercepted  or  wait  until  after  the  mission;  therefore,  the  data 
link  may  be  on  or  off  at  any  given  moment. 

The  sensors  usually  operate  in  groups  of  two  or  three  for  DF  fixing;  lines 
of  bearing  from  individual  sensors  are  correlated  to  produce  target  locations. 
The  geographical  area  covered  is  dependent  on  the  sensor's  sector  scan  (in 
degrees)  and  height  (for  airborne  sensors). Movement  of  airborne  sensors  is 
confined  to  the  mission  itself,  e.g.,  an  elliptical  flight  path  behind  the  FEBA, 
and  travel  to  and  from  that  path;  movement  of  ground  sensors  is  based  on  the 
combat  situation  and  is  generally  determined  by  the  movement  of  the 
supported  echelon  (about  twice  a  day  for  division). 


Three  types  of  reports  are  sent  back  to  the  TCAE: 

1)  sensor  location,  operational  status 

2)  technical  reports  -  These  may  include  frequencies  intercepted  and 
lines  of  bearing  for  analysis,  and  will  be  passed  on  to  the  user  after 
analysis,  stripped  of  any  codeword  information. 

3)  user  product  (T  AC  REP,  TACELINT)  -  This  is  immediately  usable 
information  normally  requiring  no  analysis.  Usually  it  goes  through 
the  TCAE  first,  but  may  be  sent  directly  to  the  ultimate  user  if 
necessary  and  if  it  contains  no  codeword  information. 

2.1.2  Moving  Target  Indicator  (MTI)  Employment 


The  BEM  represents  both  ground-based  and  airborne  MTI  radars,  the 
ground  based  being  a  generic  ground  surveillance  radar  (GSR)  and  the  airborne 
being  a  side-looking  airborne  radar  (SLAR). 

2. 1.2.1  Ground-Based  MTI  (GSR) 


The  GSRs  with  which  the  BEM  is  concerned  are  organic  to  the  Ground 
Surveillance  Company  of  the  CEWI  Battalion,  although  they  are  usually 
attached  to  maneuver  brigades  or  battalions.  Therefore,  depending  on  the 
sensor  used,  the  radar  teams  may  be  tasked  by  maneuver  battalions,  brigades, 
or  divisions. 


Collection 

GSR's  are  placed  in  stationary  positions,  usually  500  meters  to  1  Km 
behind  the  FEBA  and,  depending  on  the  sensor,  may  be  carried  by  personnel  or 
on  vehicles.  They  are  used  to  detect  moving  targets,  either  personnel  or 
vehicles,  and  employ  random  operating  periods  of  short  duration  to  avoid 
detection. 


GSR's  provide  information  on  the  range,  azimuth,  elevation,  direction  of 
movement,  and  vehicle  type  (tracked  or  wheeled);  since  GSRs  are  usually 
attached  to  a  maneuver  echelon,  reports  are  usually  sent  to  the  intelligence 
organization  of  that  supported  echelon. 

2. 1.2.2  Airborne  MT1  (SLAR) 

Tasking 

Various  platforms  such  as  the  Army's  OV-1D  and  Air  Force  high-altitude 
aircraft  may  be  furnished  with  SLAR  equipment;  the  platform  used  so  far  in 
the  BEM  is  the  OV-1D  fixed-wing  aircraft.  Since  this  aircraft  is  a  corps 
asset, tasking  is  done  by  corps  through  the  corps  mission  management 
element.  The  SLAR  is  tasked  to  detect  enemy  force  movements  and  changes 
in  enemy  activity  patterns;  it  may  also  perform  rear  area  protection  (RAP) 
and  operations  security  (OPSEC)  support  function. 

Collection 

The  SLAR  is  used  mainly  as  an  MTI  collector  but  also  has  a  fixed  target 
indicator  (FTI)  capability:  its  output  is  a  two-channel  film,  one  channel 
showing  fixed-target  imagery  and  the  other  showing  bright  spots  indicating 
movement.  The  platform  generally  flies  a  racetrack  pattern  across  the  corps 
front,  approximately  30  Km  behind  the  forward  edge  of  the  battle  area 
(FEBA).  The  SLAR  is  unable  to  distinguish  target  types  or  to  differentiate 
enemy  and  friendly  targets;  it  reports  only  the  radial  components  of  the 
target's  velocity,  not  the  transverse. 


The  SLAR  film  is  processed  in  flight,  with  a  near  real-time  display  in  the 
cockpit;  in  addition,  the  output  may  be  data  linked  for  simultaneous  display  at 
ground  data  terminals  located  with  the  supported  units.  The  data  is  forwarded 
to  the  corps  CEWI  Group  (TCAE). 
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The  CM/CB  radars  are  organic  to  the  division  target  acquisition  battery, 
and  are  tasked  by  division  artillery. 

Collection 

CM/CB  radars  are  used  to  locate  enemy  mortars,  artillery,  and  rockets. 
They  are  deployed  several  kilometers  behind  the  FEBA  and  operate  by  back- 
plotting  the  weapon's  trajectory. 


Target  location  and  time  are  data-linked  to  the  direct  support  or  general 
support  artillery  battalions. 

2.1.4  IMINT  Employment 

The  two  types  of  imagery  researc  hed  for  in  the  BEM  are  photography  and 
imaging  radars;  representation  of  infra-red  (IR)  photography  is  not  planned  for 
the  near  future.  Imagery  as  currently  represented  in  the  BEM  consists  of  OV¬ 
ID  overflight;  the  following  paragraphs  on  photography  and  imaging  radars 
describe  future  capabilities  of  the  BEM. 

2. 1.4.1  Photography 

Tasking 

Because  the  immediate  need  is  for  photography  deeper  in  the  enemy's 
rear  areas,  the  BEM  will  be  representing  penetration  missions  rather  than 
stand-off  photography.  The  major  platform  for  this  type  mission  would  be  an 
Air  Force  high-altitude  aircraft;  therefore,  the  tasking  for  the  sorties  is  an 
Air  Force  responsibility,  with  a  specified  number  of  sorties  allotted  to  fill 
Army  photo  requirements. 

Collection 

Photo  missions  will  be  flown  once  or  twice  a  day,  usually  between  1000 
and  1400  hrs  when  lighting  conditions  are  favorable.  The  flight  path  used  in 
the  BEM  will  be  a  straight  line,  since  the  high  speed  of  the  aircraft  allows  it 
to  cover  the  BEM's  battlefield  in  a  matter  of  seconds  and  the  aircraft  requires 


200  miles  for  turning.  The  aircraft  cameras  take  a  series  of  still  pictures  of 
an  area  approximately  40  miles  wide. 

Reporting 

The  film  must  be  taken  to  a  ground  imagery  interpretation  center  at 
corps  for  developing  and  interpretation;  this  can  cause  a  delay  of  four  to  five 
hours  between  collection  and  reporting  to  the  corps  CEWI  Group  (TCAE). 

2. 1.4. 2  Imaging  Radars 

The  imaging  radar  represented  in  the  BEM  is  the  Synthetic  Aperture 
Radar  (SAR). 

Tasking 

Tasking  of  the  SAR  depends  on  the  platform  used.  The  platforms 
considered  here  are  the  Army's  OV-1D  aircraft  and  an  Air  Force  high-altitude 
aircraft  (see  paragraph  2. 1.2.2  for  OV-1D  tasking  and  2. 1.4.1  for  Air  Force 
high  altitude  aircraft  tasking). 

Collection 

Collection  is  usually  done  during  penetration  missions  and  results  in  a 
precise  digital  image  that  has  the  appearance  of  a  photographic  negative. 

Reporting 

Since  the  output  is  a  digital  image,  there  is  no  delay  for  ground 
processing;  the  image  can  be  linked  directly  to  the  CEWI  Group  at  Corps 
(TCAE). 

2.2  Sensor  Properties 

Table  1-1  below  shows  the  properties  currently  used  in  the  BEM  for  each 
generic  sensor  type  modeled;  see  Section  3  for  more  detailed  properties  to  be 
used  in  the  formal  sensor  models. 


3.0  FUTURE  EFFORTS 


Future  efforts  of  concern  here  are  in  two  areas  -  the  addition  of  formal 
sensor  models  and  the  use  of  realistic  message  formats  for  sensor  reports.  The 
paragraphs  below  outline  the  data  required  for  these  efforts. 

3.1  Data  for  Formal  Sensor  Models 


Listed  in  the  tables  below  are  suggested  properties  of  each  of  the  sensor 
types  which  will  be  represented  in  the  future  by  a  formal  sensor  model.  For 
each  sensor  type,  properties  are  given  for  the  platform,  collector,  and  ground 
processing  station;  some  of  these  properties  were  suggested  by  references  2,7, 
and  8.  Properties  are  listed  for  jamming  systems  and  remotely  monitored 
sensors  (REMS),  although  these  systems  will  probably  not  be  included  in  the 
near  future. 

It  should  be  understood  that  these  properties  are  likely  to  change 
somewhat;  they  are  included  here  as  an  indication  of  the  level  of  detail 
planned. 

3.2  Message  Formats 

THE  COMINT  reports  in  the  BEM  currently  contain  only  message 
internals  -  such  characteristics  as  frequency  and  start/stop  times.  It  is 
expected  that  in  the  future,  report  representation  will  be  augmented  to 
include  the  text  of  COMINT  interceptions  as  well  as  formatted  messages  such 
as  TACELINT.  PEAR.  SITREP.  etc. 


Table  1-2 

Generic  SIGINT  System 
Platform  Characteristics 

Factor  Units 


Payload 

Range 

Time  on  station 

Max  speed 

Operational  speed 

Max  height 

Operational  height 

Fuel  load 

Crew  required 

Survivability  index 

Tracks-Ground  system  only 

Wheels-Ground  system  only 

Type 

Location 

No.  of  platforms 

Vulnerabilities 

Mean  time  between  failures 

Mean  time  to  repair 


lb. 

km 

minutes 

knots  or  km/h 

knots  or  km/h 

meters 

meters 

lbs. 

n 

n 

n 

n 

ground  or  air 

km  from  FEBA,  or  x, 

n 

ADA,  weather,  etc. 

hours 

hours 


y,  (z) 


LOO 


Table  1-3 

Generic  SIGINT  System 
Collector  Characteristics 


Factor 

Crew  required 
Frequency  range 
Modulation 

Sensitivity 

Location  error  -  range 
Location  error  -  azimuth 
DF  fix  accuracy 
Coverage  range 
Sector  scan 
Revisit  time 
Mean  processing  time 
Saturation  rate 
Method  of  reporting 
Reporting  speed 
Freq,  measurement  error 
PRF  measurement  error 
PW  measurement  error 
Frequency  hop  capability 
Pulse  stagger  capability 
Constraints 
Data  link 

Mean  time  between  failures 
Mean  time  to  repair 


Units 

n 

n  ..  nMHz 

AM,  CW,  SSB,  PM  (COMINT 

only) 

db 

meters 

degrees 

meters 

km 

degrees 

seconds 

seconds 

#  intercepts/minute 
means 

#  reports/minute 
MHz 

sec.  (ELINT  only) 
sec.  (ELINT  only) 

Y/N  (ELINT  only) 

Y/N  (ELINT  only) 

LOS,  distance,  etc. 

Y/N,  to  where 

hours 

hours 


101 


Table  1-4 

Generic  SIGINT  System 
Ground  Processing  Station  Characteristics 

Factor  Units 


Crew  required 
Tether  range  to  platform 
#  collectors  at  one  time 
Mean  processing  delay 
Mean  communications  delay 
Saturation  rate 
Location 

Number  of  receivers 

Channels  per  receiver 

Collectible  frequency  (eac h  c hannel) 


n 

km 

n 

minutes 

minutes 

#  reports/minute 
km  from  FEBA,  or  x,  y 
n 
n 

n..nMHz 


Table  1-5 

Generic  Photo  Imagery  System 
Platform  Characteristics 


Factor 

Range 

Time  on  station 

Max  speed 

Operational  speed 

Max  height 

Operational  height 

Fuel  load 

Crew  required 

Survivability  index 

Number  of  platforma 

Location 

Vulnerabilities 

Mean  time  between  failures 

Mean  time  to  repair 


Units 

km 

min. 

knots 

knots 

meters 

meters 

lb. 

n 

n 

n 

x,  y,  z 

ADA,  weather,  etc. 

hours 

hours 
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Table  1-6 

Generic  Photo  Imagery  System 
Collector  Characteristics 


Factor 


Units 


Mean  process  delay 
Data  linked 

-  obscuration  factors 

-  min/max  look  angle 

-  area  covered/opn.ht. 
Crew  Required 
Collection  means 


Mean  time  between  failures 
Mean  time  to  repair 


seconds 

n 

foliage,  clouds,  light 

conditions 

degrees 

sq.km 

n 

film  or  electro- 
optical  (if  electro- 
optical,  ground 
station  processing 
delay  is  0) 
hours 
hours 


Table  1-7 

Generic  Photo  Imagery  System 
Ground  Processing  Station  Chacteristics 


Factor 


Units 


Mean  process  delay 
Mean  commo  delay 
Crew  required 
Saturation  rate 
#  collectors  at  a  time 
Location 


reports/min. 

n 

km  from  FEBA,or  x, 


Table  1-8 

Generic  IR  System 
Platform  Characteristics 


Factor 


Units 


Range 

Time  on  station 
Max  speed 
Operational  speed 
Max  height 
Operational  height 
Fuel  load 
Crew  required 
Survivability  index 
Number  of  platforms 
Location 
Vulnerabilities 

Mean  time  between  failures 
Mean  time  to  repair 


km 

min. 

knots 

knots 

meters 

meters 

lbs. 

n 

n 

n 

y,  z 

ADA  (because  of  low 
flight),  weather,  etc. 
hours 
hours 
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Table  1-11 

Generic  Imaging  Radar  System 
Platform  Characteristics 

factor  Units 


Type 

Range 

Time  on  station 

Max  speed 

Operational  speed 

Max  height 

Operational  height 

Fuel  load 

Crew  required 

Survivability  index 

Number  of  platforms 

Location 

Vulnerabilities 

Mean  time  between  failures 

Mean  time  to  repair 


air,  ground,  manpack 

km 

min. 

knots 

knots 

meters 

meters 

lb. 

n 

n 

n 

x,  y,  (z) 

ADA,  weather,  etc. 

hours 

hours 


Table  1-12 

Generic  Imaging  Radar  System 
Collector  Characteristics 


Factor 


Units 


Type 

Crew  required 
Area  covered  at  operational 
height 

Mean  process  delay 
Data  linked 

Range  at  operational  height 
Angular  resolution 
Output 

Vulnerabilities 

Mean  time  between  failures 

Mean  time  to  repair 


radar  type 
n 

square  km 

seconds 
Y/N,  to  where 
meters 
degrees 

digital  display,  film 
active  emitter 
hours 
hours 
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Table  1-1 3 

Generic  Imaging  Radar  System 
Ground  Processing  Station  Characteristics 


Factor 


Units 


Mean  processing  delay 
Mean  com  mo  delay 
Crew  required 
Saturation  rate 
#  collectors  at  a  time 
Location 


mm. 

min. 

n 

reports/m  in. 
n 

km  from  FEB  A,  or  x,  y 


Table  1-14 
Generic  MTI  System 
Platform  Characteristics 


Factor 

Type 

Location 

Number  of  platforms 
Range 

Time  on  station 
Max  speed 
Operational  speed 
Max  height 
Operational  height 
Fuel  load 
Crew  required 
Survivability  index 
Vulnerabilities 
Tracks 
Wheels 

Mean  time  between  failures 
Mean  time  to  repair 


Units 

air,  ground  vehicle, 
manpack 
x,  y,  (z) 
n 

km 

min. 

knots  or  Km/h 

knots  (Air  only)  or  Km/h 

meters 

meters 

lbs. 

n 

n 

ADA,  weather  for  air 
n,  ground  only 
n,  ground  only 
hours 
hours 


Table  1-15 
Generic  MTI  System 
Collector  Characteristics 


Factor 

Units 

Target  types  detected 

(tracked,  wheeled) 

personnel,  vehicles 

Constraints 

LOS,  etc. 

Data  linked 

Y/N,  to  where 

Velocity  threshold/target  type 

km/n 

Crew  required 

n 

Resolution 

meters 

Mean  process  delay 

seconds 

Range  resolution 

meters 

Angular  resolution 

degrees 

Output 

digital  display,  film 

Vulnerabilities 

active  emitter 

Mean  time  between  failures 

hours 

Mean  time  to  repair 

hours 

Power 

Watts 

Crew  required 

n 

#  collectors  at  one  time 

n 

Mean  processing  delay 

min. 

Mean  commo  delay 

min. 

Saturation  rate 

#  reports/m  in. 

Location 

km  from  FEBA,  or  x,  y 

Table  1-16 

Generic  CM/CB  System 
Platform  Characteristics 


Factor 


Units 


Number  of  platforms 

Location 

Fuel  load 

Crew  required 

Survivability  index 

Vulnerabilities 

Tracks 

Wheels 

Mean  time  between  failures 
Mean  time  to  repair 


active  emitter 


hours 

hours 


Table  1-17 

Generic  CM/CB  System 
Collector  Characteristics 


Factor 


Units 


Frequency  range 
Range  resolution 
Angular  resolution 
Reporting  speed 
Constraints 
Output 


Mean  processing  delay 

Target  types  detected 

Data  linked 

Vulnerabilities 

Crew  required 

Mean  time  between  failures 

Mean  time  to  repair 


n..n 

meters 

degrees 

reports  per  minute 
limited  operator  time 
real-time  target 
location;  hardcopy 
seconds 

artillery,  mortars 
Y/N,  to  where 
active  emitter 
n 

hours 

hours 


N.  \  ' 

*  •'  >V- 


WTO 
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Table  1-18 

Generic  CM/CB  System 

Ground  Processing  Station 

Characteristics 

Fac  tor 

Units 

Crew  required 

n 

#  collectors  at  one  time 

n 

Mean  processing  delay 

min. 

Mean  com  mo  delay 

min. 

Saturation  rate 

#  reports/min. 

Location 

Table  1-19 

km  from  FEBA,  or 
x,  y 

Generic  REMS  System 

Collector  Characteristics 

Fac  tor 

Units 

Sensing  life 

hours 

Frequency  range 

n..nMHz 

Accuracy 

emplacement 

Data  link 

Y/N,  to  where 

Range 

km 

Constraints 

emplacement  may  require 
penetration  of  enemy 
territory 

Vulnerabilites 

environmental  noise,  heat 
vibrations,  etc. 

Mean  processing  time 

seconds 

Location 

x,  y 

Output 

target  locations, 
number,  direction 

Saturation  rate 

#  reports/min. 

Table  1-20 

Generic  REMS  System 
Monitor  Characteristics 

Factor  V-Dllj 

Channels 

#  collectors  monitored 
Location 

Mean  processing  delay 
Mean  commo  delay 
Saturation  rate 


Table  1-21 

Generic  Jamming  System 
Platform  Characteristics 


Factor 

Unit 

Type 

air  or  ground 

Crew  required 

n 

Fuel  load 

lbs. 

Location 

x,  y 

Survivability  index 

n 

Vulnerabilities 

AD  for  air 

Tracks 

n 

Wheels 

n 

Mean  time  between  failures 

hours 

Mean  time  to  repair 

hou  rs 

Max  speed 

knots  or  km/h 

Operational  speed 

knots  or  km/h 

n 

n 

x,  y;  or  with  what  unit 

min. 

min. 

#  reports/min. 
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Table  1-22 

Generic  Jamming  System 

Jammer  Characteristics 

Factor 

Units 

Frequency  range 

n..n 

Power 

Watts 

Data  link 

Y/N,  to  where 

Constraints 

frequency  limits  to  avoid 

jamming  friendly  emitters 

Vulnerabilities 

enemy  ECCM 

Location 

x,  y 

Output 

FM,  CW,  AM,  SSB,  PM 

Mean  time  between  failures 

hours 

Mean  time  to  repair 

hours 

Coordination  Draft),  June 


2.  The  MITRE  Corporation,  Army  Intelligence  Capabilities  Reference 
Handbook  (U),  MTR-79W00461,  R.  P.  Bonasso,  November  1979,  SECRET. 

3.  U.S.  Army  Command  and  General  Staff  College,  Electronic  Warfare 
Operations,  July  1980. 

4.  U.S.  Army  Electronics  Materiel  Readiness  Activity,  USAEMRA  Tactical 
SIGINT/EW  Reference  Guide,  July  1982.  5. Discussions  with  MITRE  personnel. 


5.  Discussions  at  Signals  Warfare  Lab,  May  5,  1983. 

6.  Discussions  with  MITRE  personnel. 

7.  The  MITRE  Corporation,  Current,  Planned,  and  Future  Army  Sensor 
Capabilities  -  Working  Input  to  Critical  Nodes  Targeting  Study  )U),  DRAFT,  E 
J.  Boyle,  B.  Hart,  June  1982,  SECRET. 

8.  TRW,  POSSIM  Methodology  Manual  (Preliminary),  (U),  CDRL  A018, 
October  1979,  SECRET 

9.  Department  of  the  Army,  Training  Circular  34-50,  Reconnaissance  and 
Surveillance  Handbook,  January,  1980 


TABLE  OF  CONTENTS 


1.0  INTRODUCTION 

1.1  Purpose 

1.2  Outline  of  the  Appendix 

2.0  SUMMARY 

3.0  SCENARIO 

3.1  Description  and  Sources 

3.2  Unit  Representation 

3.3  Scenario  Development 

4.0  FORCE  STRUCTURE 

5.0  GENERIC  UNIT  DATA 

5.1  Equipment 

5.2  Radio  Nets 

5.3  Other  Data 

6.0  FUTURE  EFFORTS 


REFERENCES 


1.0  INTRODUCTION 


1.1  Purpose 

This  appendix  is  intended  to  describe  the  research  conducted  to  derive 
the  Soviet  threat  data  used  to  support  the  Battlefield  Environment  Module 
(BEM)  developed  in  MITRE's  Secure  Processing  Laboratory  (SPL).  The  BEM 
supplies  the  battlefield  environment  —  the  Red  units,  their 
moving/shooting/emitting  events,  and  Blue  sensors  —  and  produces  threat 
observables  and  Blue  sensor  detection  for  use  by  ANALYST,  a  developing 
expert  system  for  intelligence  fusion. 

1.2  Outline  of  the  Appendix 

Section  2  provides  a  short  summary  of  the  intent  of  the  threat  research 
discussed  in  this  appendix  and  some  of  the  problems  encountered.  Section  3 
describes  the  scenario  used  as  a  basis  for  the  SPL  simulation  and  the 
development  of  that  scenario  over  time.  Section  4  describes  the 
representative  force  structure  used,  and  Section  5  details  the  characteristics 
of  the  generic  unit  types  used  in  the  simulation.  Finally,  Section  6  provides  a 
glimpse  of  the  future  efforts  needed  in  threat  research  for  the  SPL.  Appendix 
in  of  this  paper,  published  separately,  consists  of  the  data  lists,  such  as  tables 
of  unit  positions,  radio  nets,  and  generic  unit  data. 
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2.0  SUMMARY 


The  picture  that  emerges  from  this  research  is  intended  to  fit  the 
purposes  of  the  SPL;  that  is,  it  is  required  to  support  a  scenario  that  will 
produce  a  sufficient  number  of  threat  observables  with  sufficient  realism  to 
adequately  test  the  fusion  capability  of  the  ANALYST  system.  For  this 
reason,  it  is  intended  to  be  a  representative  portrayal  of  the  threat  rather 
than  an  exhaustive  one. 

In  researching  a  subject  such  as  the  Soviet  threat,  several  factors 
conspire  against  a  perfect  representation:  threat  organizations  and  equipment 
are  constantly  changing  while  the  system  needs  to  be  continuously  in  use  and 
development,  and  various  sources  provide  conflicting  data  which  need  to  be 
reconciled  before  being  entered  into  the  system.  In  addition,  the 
classification  of  sources  can  be  a  problem;  because  of  computer  facility 
restrictions,  it  was  necessary  in  the  earlier  stages  of  research  to  keep  the 
data  at  the  unclassified  level.  It  is  now  possible  to  run  SECRET  level  data, 
with  a  higher  level  capability  planned  for  the  future.  These  increased 
capabilities  will  necessitate  changes  in  the  data;  it  is  expected  that  the 
object-oriented  approach  used  in  the  evolving  system  will  facilitate 
incorporating  those  changes  into  the  system. 


3.0  SCENARIO 


3.1  Description  and  Sources 

The  scenario  used  for  the  simulation  is  based  on  the  Scenario  Oriented 
Recurring  Evaluation  System  (SCORES),  Europe  I  Sequence  2A,  in  which  the 
U.S.  Army  V  Corps  defends/delays  against  an  attack  by  the  Soviet  1st  Guards 
Tank  Army  east  of  Fulda,  in  the  Federal  Republic  of  Germany.  In  keeping 
with  the  objective  of  producing  threat  moving,  shooting,  and  emitting 
observables,  only  Soviet  units  are  portrayed  in  the  simulation.  In  order  to 
provide  a  representative  sampling  of  units  and  procedures,  the  organizations 
selected  for  the  simulation  are  a  first-echelon  tank  division,  the  6th  Guards 
Tank  Division,  a  second-echelon  motorized  rifle  division,  the  27th  Motorized 
Rifle  Division,  and  essential  Army-level  units.  The  time  period  covered  is 
from  0330  on  the  second  day  of  combat  to  0330  on  the  third  day. 

The  sources  used  as  a  starting  point  for  the  scenario  development  were 
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the  SCORES  documentation  and  MITRE  documents.  Alterations  made  to 
the  scenario  portrayed  by  these  documents  are  described  in  Section  3.3.  In 
addition,  some  unit  capabilities  were  referenced  from  documentation  for  the 
Corps/Division  Evaluation  Model  (CORDIVEM).^ 

3.2  Unit  Representation 

Each  unit  in  the  scenario  is  given  a  unit  type  number  from  one  to  sixty; 
this  number  corresponds  to  one  of  the  unit  types  in  the  Generic  Unit  Data  File 
and  indicates  the  equipment  and  other  characteristics  of  the  unit.  The  unit  is 
further  identified  by  a  unique,  eight-digit  unit  identification  number  of  the 
form  CC/BB/RR/DD,  which  identifies  the  company  number  and  the  battalion, 
regiment,  and  division  to  which  the  unit  belongs.  Segments  of  the  format 
which  do  not  apply  are  filled  with  zeros;  for  example,  the  antitank  battalion 
command  post  which  is  organic  to  Army  has  the  number  00/83/00/00,  since  it 
is  not  a  company  and  is  subordinate  to  neither  a  regiment  nor  a  division. 


Each  unit  is  assigned  a  geographical  position  for  the  beginning  of  each 
timeslice  of  the  scenario  period;  these  timeslices  are  0330—0930  D+l,  0930— 
2130  D+l,  2130  D+l-0330  D+2,  and  0330—0930  D+2.  For  each  of  these 
timeslices,  each  unit  is  given  a  status  code  indicating  "assembled,"  "moving," 
or  "in  contact,"  according  to  its  activity  in  that  time  period;  if  the  unit  is  an 
artillery  unit,  it  is  also  given  a  number  indicating  the  regiment  it  supports 
during  the  timeslice. 

Below  is  a  listing  of  the  unit  types  and  their  basic  capabilities,  organized 
by  functional  area. 

3.3  Scenario  Development 

Several  changes  were  made  to  the  scenario  as  portrayed  in  SCORES. 
First,  the  level  of  resolution  was  extended  downward  from  the  battalion  to  the 
company.  Next,  unit  positions  were  refined  to  more  closely  reflect  terrain 
restrictions.  Then  units  were  added  to  the  scenario  which  had  not  been 
included  in  SCORES,  such  as  division  and  maneuver  regiment  forward 
command  posts,  and  the  antitank  battalion  and  independent  tank  battalion  of 
the  second  echelon  division.  Finally,  the  representation  was  expanded  upward 
to  include  Army-level  units. 

The  system  is  currently  running  at  the  level  of  one  division,  with  data 
available  for  the  two  divisions  and  Army  units. 


MANEUVER  UNITS 


NAME 


CAPABILITIES 


MR  CO 

NOT  USED 

MR  BN  CP 

MR  RGT  FWD  CP 
(forward  position  of  CMDR) 

MR  RGT  MAIN  CP 

MR  DIV  FWD  CP 
1  Independent  TK  BN  (com¬ 
mander's  forward  position) 
MR  DIV  MAIN  CP 
1  Independent  TK  BN 


maneuver,  delivery  of  fires 

C2  of  3  MR  CO's 

C2  of  3  MR  BN’S  &  1  TK  BN 

C2  of  3  MR  BN’s  &  1  TK  BN 
C2  of  3  MR  ROT’S,  1  TK  RGT, 

C2  of  3  MR  RGT’s,  1  TK  RGT, 


TK  CO 

NOT  USED 

TK  BN  CP 

TK  RGT  FWD  CP 
Commander 

TK  RGT  MAIN  CP 

TK  DIV  FWD  CP 
Commander 

TK  DIV  MAIN  CP 

TK  ARMY  FWD  CP 
Commander 


Maneuver,  delivery  of  fires 

9 

C  of  3  tank  companies 
Forward  position  of  Tank  RGT 

C2  of  3  tank  BN’S 
Forward  position  of  Tank  Div. 

C2  of  3  Tank  RGTS  &  1  MR  RGT 
Forward  position  of  Tank  Army 

C2  of  Tank  Division  &  1  MR  Div. 


TK  ARMY  MAIN  CP 


Table  H-2 
ENGINEER  UNITS 


TYPE  NAME  CAPABILITIES 


52 

Army  Eng.  RGT  CP 

C^  of  Army  Construction  BN 
(type  53)  &  Army  Engr.  BN 
(type  33) 

53 

Army  Construction  BN 
(considered  action 

o 

Emplace  and  remove  span 
bridges 

unit,  not  broken 
further) 

0 

0 

Road  construction  & 
maintenance 

Operate  Sawmill 

33 

Eng.  BN  (Army) 
(considered  action 
unit,  not  broken 
further) 

o 

water  crossing-boats,  ferries, 
amphibians,  truck  launched 
bridges 

0 

Emplace  &  remove  counter 
mobility  obstacles,  (mines, 
abatis,  booby  trap*,  craters, 
etc.) 

56 

Army  Pontoon  RGT 
(action  unit,  not 
broken  down) 

0 

Emplace  &  remove  pontoon 
bridges 

0 

Launch  and  recover  amphibians 

57 

Army  Assault  Crossing 

BN  (not  broken  down 

o 

Launch  tracked  ferries  and 
amphibians  (not  bridges) 

33 

Eng.  BN  CP  (Div) 

o 

C  of  Pontoon  Co;  Assault 
Crossing  Co,  (also,  there  is  a 
"Road-Bridge  Const.  Co."  at 
Div.,  it  is  omitted  along  with 
"technical  Co.",  etc.) 

(Capabilities  are  based  on  inferences  from  equipment  tables,  and 
sane  capabilities  listed  in  Red  FARO'S;  however,  Red  FARO's  show 
different  units,  so  again,  inferences  were  made.) 


Table  II-3 

ARTILLERY  UNITS 


TYPE 

NAME 

CAPABILITIES 

15 

ARTY  BTRY  (122) 

fire  support  to  maneuver 
regiments  (Div.  artillery 

RGT) 

16 

ARTY  BN  CP  (122) 

C2  of  3  -  122  Batteries  (Div. 
Artillery  RGT) 

17 

GUN-HOW  or  Howitzer 

BTRY  (152) 

fire  support  to  division  units 
(Army  Artillery  RGT) 

18 

GUN-HOW  or  Howitzer 

BN  CP  (152) 

C2  of  3  - 152  Batteries  (Army 
Artillery  RGT) 

19 

GUN  BTRY  (130) 

fire  support  to  division  units 
(Army  Artillery  RGT) 

20 

GUN  BN  CP  (130) 

C2  of  3  -  130  Batteries  (Army 
Artillery  RGT) 

21 

ARTY  RGT  CP  (Div. 
or  Army) 

O 

C  of  artillery  batteries  for 
Division  or  Army 

41 

TGT.  ACQ.  BTRY  (ARTY 
RGT.,  Div.  or  Army) 

Radar  acquisition  of  ground 
targets 

22 

FROG  BTRY 

Chemical,  nuclear  coventional, 
long  range  fire  capability 
against  targets  in  enemy  area 

23 

FROG  BN  CP 

C^  of  3  FROG  batteries 

24 

MRL BTRY 

Multi-barreled  rocket 
launehers,  heavy  fire  on  high- 
priority  targets  at  decisive 
points,  chemical  or 
conventional 

25 

MRL BN  CP 

C2  of  3  MRL  batteries 

42 

NOT  USED 

43 

NOT  USED 

125 


(Table  II-3) 
(Concluded) 


TYPE 

NAME 

CAPABILITIES 

49 

SCUD  Bde  CP 

C2  of  3  SCUD  BN’S 

50 

SCUD  BN  CP 

C2  of  3  SCUD  Btry’s 

51 

SCUD  Btry 

Fire  support  for  Army 
operations  (conventional, 
nuclear,  or  chemical  missiles 
to  range  of  280  KM,  tracked  i 
wheeled  vehicle  launcher) 

58 

Antitank  BN 

Army/MR  Div 

C2  of  2  Antitank  Batteries 
and  1  ATGM  Battery 

59 

Antitank  Btry. 
Army/MR  Div 

Provide  antitank  support  to 
unit  (guns) 

60 

*ATGM  Btry 

Army/MR  Div 

Provide  antitank  support  to 
maneuver  units  (guided 
missiles)  -  effective  range 

4-5  Km 


*Ant i -tank  miss i  le  battery  also  exists  in  each  TK  <3c  MR  RGT,  but  has 
not  been  included  here. 


Table  n-4 

AIR  DEFENSE  UNITS 


NAME 


CAPABILITIES 


SA-6  BTRY 


SA-6-TGT-ACQ  BTRY 

SA-6  RGT  CP 

SA-4  Bde  CP 
SA-4  BN  CP 
SA-4  Btry 


Engage  low-to-medium  altitude 
attacking  aircraft  and 
helicopters;  area  defense  to 
division,  point  defense  to 
maneuver  regiments,  Division 
HQ, and  FROG  BN 

Radar  acquisition  of  enemy 
aircraft  targets 

C2  of  SA-6  BTRY's,  &  TGT 
ACQ  BTRY 

C2  of  3  SA-4  BN'S 

C2  of  3  SA-4  Btry's 

Acquire  &  engage  medium-to- 
high  altitude  aircraft  attacking 
divisions,  Army  HQ,  or  SSM 
Bde  (No  TAB  for  SA^I; 
acquisition  radars  are  in  the 
batteries) 


Table  H-5 
CSS  UNITS 


TYPE 

NAME 

CAPABILITIES 

29 

MTCE  CO.  (of 
maneuver  RGT's) 

Light  repairs,  clear  damaged 
vehicles  from  roads,  report  to 
Div.  MTCE  BN  repairs  beyond 
capabilities 

34 

Div.  MTCE  BN 

Division  level  repair,  recovery, 
clearing  routes  of  damaged 
vehicles 

30 

Medical  Co.  (of 

RGT's) 

Emergency  medical  treatment, 
evacuation  to  Regimental 
Medical  Points  from  BN 
Medical  Points,  notify  Div. 

Med  BN  to  pick  up 
casualties 

35 

Div.  Med.  BN 

Collection  from  Regimental 
Medical  Points  to  Divisional 
Reception  Stations,  triage, 
treatment  (including  surgery) 
evacuation  to  Army-Front 
hospitals 

31 

*Motor  Transp.  Co. 
maneuver  RGT's 

Transport  supplies  to  maneuver 
BN'S  (all  classes  of  supply) 

32 

*Supply  &  Service 

Pltn  (of  Maneuver 

RGT'S) 

Food  and  water  supply 

36 

*Motor  Transp.  BN 
(Div  or  Army) 

Transport  supplies  to 
maneuver  regiments  (or 
divisions)Call  classes, 
but  apparently  not  POL  at 

Army  since  there  is  an  Army 
POL  BN) 
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TABLE  n-5 
(Concluded) 


TYPE  NAME 


CAPABILITIES 


54  Army  Motor  Transp 
RGT  CP 

55  *Army  POL  Transp. 
BN  CP 


of  Army  Motor  Transp.  BN 
Army  POL  BN 

POL  transp.  down  to  Div 


* 

In  maneuver  HOT'S,  MT  CD'S  are  assumed  to  do  PCX  supply  (since  they 
have  the  PCX  trucks)  along  with  amnuni tition;  the  S5cS  GO'S  are 
assumed  to  do  food-water  (since  they  have  kitchen  and  water 
trailers).  At  division,  MT  BN  does  all  3  (with  AMO  00,  POL  CD’S  <Sc 
S&S  Pltn) . 


4.0  FORCE  STRUCTURE 


Because  of  the  equipment  first  used,  the  scope  of  the  force 
representation  was  initially  restricted  to  one  first-echelon  tank  division  at 
company-level  resolution.  The  data  has  since  been  expanded  to  include  a 
second-echelon  motorized  rifle  division  as  well  as  tank  Army-level  units. 
Only  ground  forces  are  considered. 

Figure  1-1,  1-2,  and  1-3  show  the  current  scope  of  the  force  structure. 
This  force  structure,  while  representative  of  the  major  capabilities  of  the 
Soviet  force  at  this  level/®’1®’11)  is  not  an  exact  replica  of  it.  Since  the 
research  was  conducted  over  a  three-year  period,  it  is  likely  that  force 
structure  changes  have  occurred  which  have  not  been  incorporated  yet;  the 
known  omissions  are  discussed  below. 

The  Soviet  Army  now  includes  a  motorized  rifle  battalion  in  the  tank 
regiment;  this  unit  should  be  added.  The  signal  companies  of  the  tank  and 
motorized  rifle  regiments  were  not  included  since  our  main  concern  was  the 
existence  of  communications  traffic  for  Blue  sensors  to  pick  up,  not  the 
establishment  and  maintenance  of  communications  facilities;  however,  when 
the  simulation  becomes  two-sided  these  units  should  be  modeled  as  significant 
actors.  The  same  is  true  of  the  reconnaissance  companies  and  chemical 
defense  companies.  The  anti-aircraft  artillery  and  missile  batteries  of  the 
motorized  rifle  regiments  are  not  explicitly  modeled,  their  weapons  and 
radars  being  included  in  their  respective  regimental  command  posts.  The 
antitank  missile  battery  of  the  motorized  rifle  regiment  should  be  included  in 
the  future;  however,  a  division-level  antitank  capability  is  represented  now  by 
the  antitank  missile  battalion  of  the  motorized  rifle  division.  The  mortar 
platoon  of  the  motorized  rifle  regiment  was  not  included  because  at  the  time 
the  research  was  conducted,  no  Blue  counter-mortar  radars  were  modeled; 
this  platoon  should  be  included. 


MOTORIZED 

RIFLE 

DIVISION 


5.0  GENERIC  UNIT  DATA 


This  section  will  describe  the  data  gathered  on  each  generic  unit  type. 
(5,7,9,12) 

5.1  Equipment 

For  each  unit  type,  data  was  gathered  on  its  vehicles,  weapons,  and 
radars. 

The  vehicles  were  divided  into  the  categories  of  tread,  with  four 
subtypes;  artillery,  with  five  subtypes;  air  defense  artillery,  with  four 
subtypes,  wheeled,  with  seven  subtypes;  and  engineer,  with  five  subtypes.  A 
file  is  kept  which  contains  performance  characteristics  for  each  of  these 
vehicles.  As  new  units  were  added  to  the  scenario,  any  vehicle  not  listed  in 
the  file  was  included  in  the  category  which  most  closely  approximated  its 
characteristics;  this  was  done  both  to  avoid  a  large  file  of  very  similar  vehicle 
characteristics  and  because  performance  characteristics  were  unavailable  for 
some  vehicles. 

Weapons  of  a  unit  type  were  put  into  the  categories  of  artillery,  tank,  or 
small  arms.  For  purposes  of  the  simulation,  the  significance  of  the  weapons 
lies  in  the  rate  of  ammunition  expenditure  for  the  unit  and  the  resulting 
requirement  for  resupply,  not  in  the  actual  weapon  count.  The  ammunition 
expenditure  is  expressed  as  tons  per  hour  per  fighting  vehicle,  and  was  derived 
in  this  way:  the  weight  of  an  ammunition  type's  unit  of  fire  (a  standard 
quantity  established  for  measuring  amounts  of  each  ammunition  type)  was 
multiplied  by  the  standard  number  of  units  of  fire  used  per  day  by  a 
particular  type  of  weapon;  this  produced  the  tons  per  day  expenditure, which 
was  divided  by  24  to  produce  the  ton-per-hour  expenditure  for  each  weapon 
type;  this  was  expressed  as  tons-per-hour  per  fighting  vehicle,  given  the 
number  of  weapons  of  that  type  on  each  vehicle. 

Radars  were  categorized  as  fire  control,  with  two  subtypes;  surveillance 
and  acquisition,  with  seven  type;  or  meteorological,  with  two  subtypes. 


Although  not  all  these  subtypes  are  represented  in  the  scenario,  a  file  of 
characteristics  was  kept  on  all  of  them  in  case  they  are  needed  as  the 
simulation  is  expanded.  In  some  cases,  some  of  the  date  were  unavailable;  in 
those  cases,  a  unit's  radars  were  recorded  as  belonging  to  the  next  most 
appropriate  subtype. 

5.2  Radio  Nets 

A  representative  radio  net  structure  has  been  recorded  for  the  two 
divisions  in  the  scenario.  Included  are  the  internal  and  alternate  internal 
command  net,  the  external  command  net,  and  the  artillery  net,  where 
appropriate  for  each  unit. 

5.3  Other  Data 

Other  data  for  each  unit  type  include  the  average  convoy  length  by  day 
and  night,  derived  by  adding  the  lengths  of  the  vehicles  in  a  unit  and  the  usual 
distance  between  them;  the  average  march  speed  by  day  and  night  when  all 
unit's  vehicles  are  traveling  together,  derived  by  determining  the  average 
speed  of  the  unit's  slowest  vehicle;  and  the  average  time  to  clear  and  close  to 
a  new  position.  This  last  item  was  an  estimate  in  many  cases,  since  the  data 
were  unavailable  for  many  units. 


6.0  FUTURE  EFFORTS 


Future  efforts  connected  with  threat  data  involve  three  tasks:  1)  the 
existing  data  will  be  incorporated  into  the  Battlefield  Environment  Module 
(BEM),  which  involves  conversion  from  a  Pascal-based  version  of  the 
simulation  to  a  Lisp-based  one;  2)  the  threat  representation  will  continue  to 
evolve  through  refinements  and  updates;  3)  sources  above  the  SECRET 
classification  should  be  consulted;  and  4)  the  scope  of  the  data  will  be 
extended  to  the  echelons-above-corps  level. 
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k  aatheaatlclan  when  receiving  (reconstruct  cycle  definition  for  >object) 
(prog  (start-tlae  stop-tine  alBBlon-start-tlae  alsslon-end-tlae 
cycle-on-duratlon  cycle-off-duration  cycle-def) 


(If  (polnt-wlthln-clrcle  (poeltion-at-tlae-t  unit 

current-tlae )  (car  aenaor-poa)  <cadr  aenaor-poa) 
(square  (ask  laenaor-teat  recall  your  range)))  then 
(aetq  time- space -overlaps  (append  tlae-apace-overlapa 
(Hat  aensor-teat) ) ) 


k  Htheuti clan  when  receiving  (determine  tiae/space  overlaps  between  /unit 
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tell  aector  plan  after  itdlff  (car  on-lnterval)  ~nclock-tlae)  ~ainutes 
laenaor  haa  penetrated  the  sector  with  I (list  sensor 
(ask  (sensor  recall  your  type)  (car  on-lnterval)  (cadr  on-lnterval))) 
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1.0  DEVELOPMENT/DEMONSTRATION  FACILITIES 


Development  of  the  BEM  has  taken  place  in  the  MITRE  Washington 
Secure  Processing  Laboratory  (SPL).  Formal  demonstration  of  a  BEM 
simulation  usually  takes  place  in  MITRE's  Command  and  Management 
Information  System  (CAMIS)  Laboratory. 

1.1  SPL  Facility 

The  SPL  is  located  within  a  special  compartmented  information 
facility.  Included  in  this  facility  are  a  VAX  11/780  with  8  megabytes  of 
memory,  one  67  megabyte  disk  drive,  two  300  megabyte  disk  drives,  and 
several  graphics  and  text  terminals.  Also  located  in  the  SPL  is  an  LMI  LISP 
machine.  Figure  V-l  shows  the  configuration  of  the  SPL.  The  BEM  runs  on 
the  VAX  11/780.  The  ANALYST  can  run  on  both  the  VAX  and  the  LISP 
machine. 

1.2  CAMIS  Facility 

The  CAMIS  Lab  is  located  next  door  to  the  SPL.  It  contains  a  VAX 
11/780  configuration  similar  to  that  in  the  SPL.  The  CAMIS  lab  contains  a 
briefing  room  where  a  graphics  terminal  display  may  be  projected  onto  a  large 
screen.  A  demonstration  may  be  shown  here  by  transferring  the  BEM 
simulation  code  by  tape  from  the  SPL  to  the  CAMIS  computer  or  by  direct 
cable  hookup  to  the  SPL  VAX.  Figure  V-2  shows  the  CAMIS  Lab 
Configuration. 
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FIGURE  V-1 
SPL  CONFIGURATION 
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FIGURE  V-2 

CAMIS  LABORATORY  CONFIGURATION 
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